We built a complete, role-secured CRM in a single AI conversation. Database, twenty API endpoints, JWT authentication, email dispatch, and a KPI dashboard with charts — live and verified in production, minutes after the first prompt.
The backend took about 60 seconds of compute and roughly six cents of tokens.
This article is the full ledger of that build: what was created, how long each step actually took (measured, where the platform measures it), what it cost, what went wrong, and what we can honestly claim about the result. A while ago I wrote about building on Magic with Qoder instead of Fable at 3–4% of the cost; this is that argument taken from benchmark to receipts — one real system, built end to end, with every number on the table.
What we built
The agent — Qoder, connected over Magic's MCP server — produced a demo CRM in one conversation:
- An SQLite database with three tables — contacts, deals, and activities — with foreign keys and defaults, seeded with 8 contacts, 10 deals ($150k open pipeline, $80k won), and 14 activities.
- Fifteen CRUD endpoints — full GET/POST/PUT/DELETE plus record counts for every table.
- Four KPI endpoints — summary stats, pipeline by stage, contacts by status, activities by type.
- One send-email endpoint that looks up a contact and dispatches through SMTP.
- A KPI dashboard with Magic-authenticated login, six KPI cards, three charts, contacts and deals tables, and an email form.
- All twenty endpoints restricted to the "guest" role — RBAC plus JWT, verified in the live endpoint registry, nothing public.
Total backend code written by hand: zero lines. The agent sent compact declarative prompts; the platform generated everything. The only hand-written code in the entire build was the dashboard frontend — plain HTML, CSS, and JavaScript.
How it was actually built
The workflow, in order: delete the previous test database and module for a clean start; create the database and three tables with SQL DDL in one call; generate twelve CRUD endpoints with the crudifier, one call per verb per table; seed 32 rows of demo data in one call; generate the send-email endpoint from a plain-English prompt (two calls — see the bug ledger); generate the four KPI endpoints from plain-English prompts; write the dashboard frontend by hand; and finally audit everything — endpoint registry, users and roles, live endpoint invocations, and SQL cross-checks against the aggregations.
Notice what is absent from that list: no scaffolding, no framework wiring, no auth implementation, no ORM configuration, no deployment step. The endpoints were live on the cloudlet the moment they were generated.
The time ledger
The Hyperlambda Generator reports its own execution time, so these six numbers are server-measured, not estimated:
| Generated endpoint | Seconds (measured) |
|---|---|
| send-email (v1) | 5.70 |
| send-email (v2, bug fix) | 4.92 |
| kpi-summary | 4.86 |
| kpi-pipeline | 2.97 |
| kpi-contacts-by-status | 4.44 |
| kpi-activities-by-type | 3.99 |
| Total, 6 calls | 26.9 s |
The twelve crudify calls report lines of code but not timing; at roughly 1.5 seconds of round-trip each, that is about 18 more seconds for 712 lines of generated CRUD.
Which gives the headline numbers:
- The entire backend — every HTTP invocation that created it — took about 60 seconds.
- Everything else — writing the frontend, reading schemas, verifying, and the agent's own reasoning — took about 300 seconds.
- Of the actual building time, the split was roughly 35% backend to 65% frontend.
Sit with that ratio for a moment. The part of the build that traditionally consumes most of a project — the secured API layer with auth, validation, and data access — was the fast part, by a wide margin. The hand-written HTML dashboard took nearly twice as long as the entire backend.
Lines of code
| Layer | LOC | Hand-written |
|---|---|---|
| Backend (12 CRUD + email + 4 KPI + SQL) | ~850 | 0 lines |
| Frontend (dashboard HTML/CSS/JS) | ~420 | all of it |
| Same app without Magic (estimate) | ~2,800 | all of it |
The cost ledger
The session consumed an estimated ~200k input and ~15k output tokens — a transparent guesstimate from context sizes, not a metered number, so treat it as order-of-magnitude.
| Price point (public list prices) | Session cost |
|---|---|
| Kimi-class ($0.60 / $2.50 per M tokens) | ≈ $0.16 |
| GPT-5-class ($1.25 / $10 per M tokens) | ≈ $0.40 |
| Sonnet-class ($3 / $15 per M tokens) | ≈ $0.79 |
At Kimi-class pricing — which is the point of driving the build with Qoder — the backend's share is about six cents. Six cents for a secured CRUD API with KPI aggregation and an email endpoint.
This is the compounding effect described in the Qoder article: when the platform generates the backend from short declarative prompts, the agent's job shrinks to the point where a budget model does it comfortably — and the token bill shrinks with it.
What would this cost without Magic?
The honest comparison is the same deliverable built by an agent with generic tooling — Express, SQLite, JWT, hand-rolled RBAC, nodemailer, plus getting it deployed somewhere: roughly 2,800 lines to write and debug, 3–5 hours of agent wall time, 500k–800k tokens once the debug loops are counted, between $0.50 and $9 in tokens depending on the model — and then a deployment surface (server, TLS, CORS, process management) that is measured in hours to days.
Against that baseline this build saved roughly 99% of the backend time, cut token cost by 3–56×, and eliminated 100% of the hand-written backend code. For the broader landscape — Lovable, Bolt, n8n, Supabase, LangChain — the order-of-magnitude estimates from public pricing all land between hours and days for the same deliverable. Those are guesstimates, not benchmarks, and I label them as such; the six-minute number from this session is the one that was measured.
The bug ledger
Two bugs. Zero shipped.
Bug one was Magic's fault. The first version of the send-email endpoint filtered the contact lookup on the wrong column name. It was caught in the mandatory code review before deployment, and the fix was a regeneration — 4.92 seconds, measured. Hand-editing generated Hyperlambda is deliberately not the workflow; you fix the prompt and regenerate, which means the fix path is the same fast path as the build path.
Bug two was the agent's fault. The first version of the dashboard sent credentials as an HTTP Basic header, but Magic's authentication endpoint takes credentials as query parameters and returns a JWT ticket. The agent read the platform's own auth guide — served over the same MCP connection — corrected the frontend, and redeployed. No human intervened.
I include this section for a reason beyond honesty theater. Both failure modes matter architecturally: the generator bug was caught by review-before-deploy, and the agent bug was self-corrected from platform documentation the agent could reach itself. Neither reached production, and neither required a person.
Security and verification
Nothing is provably "100% secure," this build included. Here is what was actually verified: all twenty endpoints confirmed guest-role-gated in the live endpoint registry, with nothing public. Three endpoints live-invoked with authenticated tooling and returning correct data. Both GROUP BY aggregations cross-checked against raw SQL with exact matches. Production login and dashboard rendering captured in browser screenshots.
The security posture is the platform's, not the build's — which is the point. Role checks run before any endpoint logic. The JWT issuer is built in, so there is no hand-rolled auth code to get wrong. Tickets rotate on a ten-minute window. The generated data layer uses parameterized queries throughout — there is no hand-concatenated SQL anywhere because no hand-written SQL exists. And the central endpoint registry means the entire auth surface can be audited in one call, which is exactly how the audit step was done.
Residual risks, stated plainly: credentials travel as query parameters (Magic's documented design — HTTPS is assumed), the JWT lives in localStorage (the standard SPA trade-off), the email endpoint is untested until SMTP credentials are configured, and no penetration test was performed. Overall confidence lands around 92% — the CRUD, KPI, and auth layers were live-verified in production; the residual is what live verification cannot claim.
What this actually demonstrates
It is tempting to read this as a speed demo, but the ratio is the real finding.
When the backend is generated — with auth, RBAC, and validation enforced by the platform rather than reimplemented per project — the backend stops being where the time, the money, and the risk live. Sixty seconds and six cents for the secured API layer means the constraint has moved: to the frontend, to the data model decisions, to the questions worth asking of the data. Those are the parts that deserve human judgment anyway.
And because the whole build ran through MCP inside role boundaries, this was not a code assistant emitting files for someone to review and deploy. It was an agent operating a production platform, with the platform — not the prompt — deciding what it could touch.
That is what Magic Cloud plus Hyperlambda feels like in practice: a complete, role-secured CRM in one conversation, with the receipts to show for it.
Magic is MIT-licensed and open source — the repository is at github.com/polterguy/magic, with documentation at docs.ainiro.io.