Auth, tenant isolation, migrations, money that survives a race — three months and $9,000–12,000 before your first feature exists.
A multi-tenant Node and Postgres API, compiled from a markdown spec and run against a live database before it reaches you.
### order
Status: pending, paid, shipped,
delivered, cancelled
Workflow: pending → paid → shipped
Business Rules:
- When an order is cancelled after
payment, refund the amount to the
customer's wallet as store credit.
WHERE clause66 lines of markdown → 7,722 lines · 85 routes · 26 tables · 21 RLS policies · 326/332 assertions passing
Three entities in, 26 tables out. The same run wires JWT auth, billing, Stripe, webhooks, cron, rate limiting and sockets — whichever your rules ask for.
Not an illustration — that is quickkart's actual spec.
The whole file ships in the repo as
SPEC.md,
next to the code it produced, so you can count the ratio yourself.
Ten minutes to compile. One to two days to deliver — the difference is me running it against a real Postgres and fixing what falls out before you see it.
Before a single feature exists, this has to be built. Every backend needs it, nobody demos it, and it is where the schedule goes.
66 to 98 developer-days. Three to five months for one person; four to seven weeks for a team of three. A quote for this work usually reads $9,000–12,000 — and three months.
| Layer | Days |
|---|---|
| Auth — signup, login, refresh, hashing, token rotation | 6–8 |
| Multi-tenancy, row-level security and roles — done properly | 10–15 |
| CRUD with validation, pagination, filters, soft delete | 6–8 |
| Money — transactions, row locks, idempotency, concurrency | 6–10 |
| Double-entry ledger, multi-currency, approvals | 11–17 |
| State machines, migrations, audit log, cron | 9–13 |
| Typed errors, rate limiting, headers, health probes, Docker | 6–9 |
| The test suite that proves any of it works | 12–18 |
The three rows in bold are the ones that get cut first when the deadline moves. Every row is generated except the last — the compiler does not write your test suite. What the one to two days buys instead is your backend run against a live Postgres by me, with whatever surfaces fixed before you get it.
In every backend, whether the spec asks or not:
JWT auth with rotating refresh tokens · row-level security Postgres enforces · role checks on every route and as a DB constraint · transactions with row locks · idempotency keys · versioned migrations · audit log · cron scheduler · rate limiting · Helmet · CORS · Docker
WHERE clause — and
bound transaction-locally, so one tenant's context cannot leak into another's query.
Measured below.CHECK
constraint in the database. Per-entity validators with an unknown-field guard, so a
client cannot set tenant_id, role or a balance from the body.
Every query parameterised.docker compose up and it serves traffic. Multi-stage
Dockerfile as non-root with a HEALTHCHECK, compose,
.env.example, checksum-tracked migrations, /health and
/ready, audit log, cron, rate limiting, Helmet, CORS, licence and docs.Not one template with the nouns replaced. Five specs, five genuinely different backends.
Five specs — e-commerce, fintech, productivity, healthcare, mobility — compiled to 348 routes · 92 tables · 67 RLS policies · 36,765 lines, from 492 lines of markdown. Two of the five are verified end to end; the other three boot but have not had the same sweep, and the limits section below says so. A boilerplate is one codebase everyone receives and then deletes from. Compare the two published backends: they share the platform and almost nothing else.
ledgerpro and quickkart share 12 platform tables — users, tokens,
audit, idempotency. The other 21 exist because a specification asked for them,
including loyalty_point_lots, which tracks points in dated lots so the oldest
expire first. Nobody wrote that table; the spec said customers earn points.
None of that logic is invented per project. The compiler ships hand-written implementations — money, billing, commerce, operations, logistics, healthcare, HR — and picks them from what your business rules say.
Integrations Twilio SMS · Google Calendar · Sheets · Drive · Gmail and SES email · S3 uploads · Google Maps — each emitted with its client, routes and credentials wired, when your spec declares it
These are not thin wrappers. The word webhooks alone produces an
outbound delivery engine: SSRF-checked at registration and again at send, HMAC-SHA256
signing with a replay window, six-attempt backoff, a SKIP LOCKED worker, and
auto-disable after 50 consecutive failures. Declare Stripe and the native billing
engine steps aside, so you never end up with two subscription systems double-counting
each other.
Logic no compiler could anticipate — surge pricing, a commission ladder — is written as a Feature Contract: its tables, formulas, thresholds, triggers and error codes, built against your real schema. When it cannot build one correctly it emits nothing and says so. It is also the one path where an LLM writes the code, and the part most likely to need your review.
Live HTTP and live SQL, two tenants actively attacking each other. The bugs that matter here — policies that never execute, a transaction helper that silently does nothing — pass a type-check and answer 200. Reading the code does not find them.
app role : forgx_app bypassrls = false invoices : 59 in the table visible : 2 — exactly its own other rows: 0
10 payments at once, one 100.00 invoice → exactly 1 accepted, 9 rejected 422 → total paid 100.00
Every route was exercised, not just the interesting ones. A separate pass walks the full API surface — all 78 endpoints — checking each one is reachable, correctly gated, and returns a typed error rather than a stack trace. It is what stops a suite from passing loudly against six endpoints.
Four assertions fail and the repository says why: signup reveals whether an address is registered, two Drive routes return 500 instead of 404, and a timing test missed its tolerance by 12ms. That last one is left failing rather than widened, because a test that cannot fail proves nothing. One line of this build was also edited by hand — an assignment that should have been a delete; the compiler still needs the same fix.
Stated here rather than discovered later.
Two backends are verified end to end — ledgerpro at 251 of 255, quickkart at 326 of 332. Three more are generated and boot but have not had the same sweep. Findings get published the day they land rather than quietly patched, which is why this list is longer than most.
users table
lets only admins write it, so a customer setting their own PIN affects zero rows while
the endpoint answers 200. It needs a self-update clause; the fix belongs in the compiler
and has not landed. Four of quickkart's six failing assertions are this.Two backends, two domains, one compiler. Each repository contains the
markdown specification it was compiled from, as SPEC.md — so the ratios below
are something you can count rather than take on trust.
An accounting and invoicing API. Invoices, payments, a double-entry ledger, an expense approval chain, FX at stored rates, and exports to Drive and Sheets.
A storefront API for vendors selling to customers. Products, orders and payments, plus a wallet that refunds cancellations as store credit, a coupon engine, fraud velocity checks, loyalty points, and reviews restricted to verified buyers.
Source-available — read it, run it, audit it; not licensed for commercial use.
Describe it and I'll email you within 24 hours with scope, a delivery date and what it would cost. Delivery is one to two days after that. Taking a small number of builds at a time.
Every figure on this page is counted from the generated source or measured against a live Postgres, and is reproducible from the test suite in each repository.