The subject has worked on two multi-tenant business systems — a CRM and a farm ERP — and both met the same wall. A CRM with one fixed idea of a “lead” is wrong for its second customer; an ERP that covers piggery, hatchery and shrimp with one generic record describes none of them well. The usual escape routes are forking per customer, or bolting on custom fields and hoping.
NavCRM’s metadata-driven fields started the thought. ZRM takes it much further: a module — its entities, fields and relationships — is a row in a database rather than a folder of code. Adding a new kind of record becomes a write, not a deploy; an industry template becomes seed data rather than a branch; two businesses run the same binary and see different products.
“Finding out whether the trade is worth it is the point of building it.”
The costs are entered plainly. Queries get indirect, so types, autocomplete and migrations that warn of breakage all have to be rebuilt. Validation moves to runtime. And the escape hatch matters more than the abstraction, because every system like this eventually meets a requirement the metadata cannot express.
The stack follows the problem. Nx, because the schema layer must agree exactly between front and back. Nuxt and Hono, because the frontend is static-first and the backend wants to be small. Drizzle over Neon, Upstash Redis for what should not touch Postgres on every request, and Clerk because authentication is a solved problem. The static frontend sits on Cloudflare Pages; the long-lived backend on a plain VPS.
Status: in progress, with no users, no uptime and no numbers, and the file will not pretend otherwise. It is here because the question it asks — how much of a business system can be data instead of code — is the one under the subject’s day job.