In-house20 products · 4 business lines · one technology base

From the shop floor to the front counter — business systems that can grow

We do not build one giant system that does everything. We let focused systems grow on one platform: one account model, one set of integration contracts, one data-authority matrix. Start with a single system, or grow all the way into the full suite.

20
in-house products
4
business lines
6
manufacturing systems, one platform
100%
can run on-premise

Product matrix

Manufacturing SuiteSix systems, one platform
ERPResource planning
PLMProduct lifecycle
APSPlanning & scheduling
MESShop-floor execution
WMSWarehouse
SRMSupplier collaboration
Restaurant SuiteFrom the till to the pickup screen
POSTill & store ops
KIOSKSelf-service kiosk
EMENUTV menu boards
PICKUPPickup calls
SHOPStore back office
OPSChain operations
AI & AutomationAI inside real processes
NOVAFLOWAI workflow
FOKEICantonese AI service
DANFAIDocument intelligence
CAD-FAIDrawings & inspection
Vertical PlatformsIndustry rules, turned into an online service
BOOKINGOnline booking
TODOTask management
LAEDrone rental
LOTTERYProbability & backtesting
Why RUYI

Fixing the real reason digitisation projects fall back to Excel

It is rarely "no system". It is several systems with no single source of truth and no reliable integration between them.

One technology base

All twenty products run the same stack: .NET 10, PostgreSQL 18, Vue 3. One response envelope, one error-code scheme, one auth model, one way to operate them. Your IT team learns it once.

One ledger per kind of data

A data-authority matrix registers exactly one system of record for each data type. Execution happens in many systems; posting happens in exactly one — adding a system never adds a second set of books.

On-premise first

Every product can be deployed to your own machines and run fully offline. Where the data lives and who can touch it is your decision, not a condition of using us.

Buy as many as you need

Enable systems one at a time and add more later. Anything not enabled falls back to the base system, so a process never breaks halfway through because "we have not bought that module yet".

Technology base

Twenty products, one stack, one way to operate them

One response envelope, one error-code scheme, one auth model, one migration convention. SQL migration scripts are the single source of truth for the schema — never ORM auto-generation. Each system runs as its own service, on its own database and port.

.NET 10One backend stack
PostgreSQL 18SQL migrations are the source of truth
Vue 3 + ViteOne frontend stack
DB-per-tenantPhysically isolated tenant databases
Linux + systemdRuns on your own servers
Android / iOSStation terminals and handhelds
Solutions

Pick a combination that already works in your industry

The same base grows into different shapes. Here are six combinations we have already delivered.

Discrete manufacturing

Delivery dates are guesswork. Nobody can say where an order stands. The drawing changed but the floor is still building the old revision. Every new system adds another set of books.

Start with ERP so the ledger is under control, then add in order of pain: APS for dates you can actually hit, MES for traceable execution, PLM so nobody builds a stale revision, then WMS and SRM. Each addition registers one more data type in the authority matrix — never two places posting the same thing.

Discrete manufacturing · Products

  • Quote a date computed from real capacity and real material availability
  • Trace every issue, pass and report back to person, machine and batch
  • Inventory and payroll stay on exactly one ledger, in ERP

Pick a combination that already works in your industry

How we deliver

Start where it hurts most — never a big-bang cutover

Solve one problem that can actually be signed off, then grow outward. Every stage has a deliverable you can accept or reject.

Site survey

We come to your floor, store or office and watch how it actually runs, then rank the pain and pick one thing that can be signed off.

Requirements blueprint

Written requirements and design: business rules, interface contracts, permissions, failure cases and the data model, spelled out and reviewed by you.

Build

Implemented against that document. SQL migrations are the source of truth for the schema. Critical logic ships with automated tests.

Pilot & acceptance

One line, one store or one department goes first, checked off against the acceptance list so problems surface small.

Rollout

Old and new entry points run side by side with a gradual switchover — never a big-bang cutover, and migrations have a rollback path.

Operations

Monitoring, backups, certificate renewal and the upgrade procedure are part of the handover, with a rollback path instead of a reinstall.

Wondering whether this fits the way you already work?

Tell us your situation, what you run today, and which part you want fixed first. You will get a concrete recommendation based on your case — not a product brochure.

Enquire