A Full-Stack CRM for $0.00: Building on Magic with OpenCode and a Free Model

A Full-Stack CRM for $0.00: Building on Magic with OpenCode and a Free Model

We built a complete, full-stack CRM in one AI conversation. A database, sixteen JWT-secured REST endpoints, and a working single-page frontend with login, a KPI dashboard, and live CRUD tables — deployed and verified in production.

The agent cost nothing. Not "cheap." Not six cents. Zero — and I did not even register an account to get it.

This is the fourth entry in a cost ledger this blog has been keeping. In July I showed Magic cutting backend build cost by roughly 80% against building from scratch. Then Qoder built the same backend at 3.4% of Fable's cost. Then a complete CRM backend landed at six cents of tokens. This is the entry where the agent column of that ledger reaches $0.00 — and where, for the first time, the agent built the whole stack, frontend included.

The agent: OpenCode and Big Pickle

OpenCode is an open-source coding agent. Out of the box it offers a set of free models, and among them sits Big Pickle — a stealth model, free for a limited time while the OpenCode team collects feedback on it, which the community widely believes to be GLM-4.6 running under a codename.

Here is the part I still find slightly absurd: I downloaded OpenCode, selected Big Pickle, and started building. No signup. No API key. No credit card on file that a "free trial" quietly converts later. The meter that every previous entry in this ledger has been reading simply is not there.

Connecting it to Magic was the same one-step affair it always is, because the integration point is MCP. OpenCode pointed at the cloudlet's MCP endpoint gets the same tools, inside the same permission boundaries, as every agent before it. Different driver, same car.

OpenCode with the Big Pickle model connected to Magic's MCP server, reading the platform guides before building the crm_test3 app

That screenshot is the actual session. Notice what the agent does before building anything: it calls whoami to ground itself, lists the platform's guides, and reads the ones that match the task. A free model, reading the manual. We will come back to why that matters.

What we built

The deliverable, in full:

  • An SQLite database, crm_test3, with three tables — companies, contacts, and deals — wired together with foreign keys: deleting a company cascades to its contacts, and a deal's contact is set to NULL if the contact goes away.
  • Sixteen generated Hyperlambda endpoints in a crm_test3 module — full GET/POST/PUT/DELETE plus record counts for every table, produced by Magic's CRUD generator.
  • Every endpoint restricted to authenticated users. Unauthenticated requests get HTTP 401, verified against the live API.
  • A complete SPA frontend — plain HTML, CSS, and JavaScript, no framework — with Magic Auth login, a KPI dashboard (open pipeline, company/contact counts, won value, a pipeline-by-stage chart), searchable tables for all three entities, modal add/edit forms with validation, and confirm-then-delete flows.
  • Seeded demo data: three companies, five contacts, six deals across every pipeline stage — $102,500 of open pipeline, $4,200 won.

It is live at app.ainiro.io/crm_test3 — log in with test / Test123! and click around.

Total backend code written by hand: zero lines. The only hand-authored artifact in the build is the frontend, and the agent wrote that too.

How it was actually built

The workflow, in order: create the database; create the three tables with SQL DDL; generate the CRUD endpoints with the crudifier, verb by verb; seed the demo data; write the three frontend files into the web root; then verify — HTTP checks on every file, a 401 check on the API, and a headless-browser render test against the real login flow.

Notice what is absent, as always: no scaffolding, no framework wiring, no auth implementation, no ORM, no deployment step. The endpoints were live the moment they were generated, and the frontend was live the moment its files were saved.

The ledger

This build
Tables3, with cascading foreign keys
Generated endpoints16, all JWT-gated
Hand-written backend code0 lines
Frontendfull SPA, written by the agent
Registration requirednone
Agent cost$0.00
Platform cost$0 — Magic is MIT-licensed

One honesty note on that table. OpenCode does not meter what it does not bill, so unlike the Qoder build — where the generator's server-measured timings put the entire backend at about 60 seconds and six cents — this session produced no token receipts to publish. The comparable numbers from that measured build are the best proxy: same platform, same CRUD generator, same class of deliverable. What changed here is that the six cents became zero, and the backend-only scope became full-stack.

The QA that a free model did

This section did not exist in the previous CRM article, because that build did not earn it. This one did.

HTTP 200 does not prove a page renders — so the build finished with a headless-browser render test against production. And because you should never point test automation at real credentials, the agent first created a throwaway test user in the guest role, then ran the whole suite as that user:

  • Login page renders with the intended palette and fonts, verified via computed styles — not by eyeballing.
  • Logged in, the dashboard KPIs matched the database: $102,500 open pipeline, four open deals, three companies, five contacts, $4,200 won. Five stage bars, five latest deals.
  • All three tables render their seeded rows — chips, links, and counts checked.
  • One end-to-end mutation through the actual UI: add a company, watch the toast fire, watch the count update.

A stray test row created along the way was cleaned up afterwards. Test hygiene, from a model that costs nothing.

The bug ledger

One bug. Zero shipped.

The username did not survive a page reload — the header greeted you as "Account" instead of the name you logged in with. The render test caught it, the fix was to persist the username to localStorage on login and clear it on logout, and the fix was verified the same way the bug was found.

And one gotcha that belongs in bold, because it will save someone a security hole: Magic's CRUD generator treats a missing auth argument as "public." Omit it and your endpoint is open to the internet. Generate with auth="*" for authenticated-only access — and then verify the 401 against the live endpoint, which is exactly what this build did.

Why a free model can do this job

The Qoder article made the argument at 3.4% of frontier cost; this build takes it to its endpoint.

An agent building a backend from scratch needs frontier-level capability, because it must design schemas, scaffold servers, wire auth, and debug the mismatches between all those layers. An agent building on Magic needs almost none of that, because the expensive primitives already exist in the platform: hosting, authentication, role-based access control, CRUD generation. The agent's job shrinks to expressing intent and verifying the result.

That is a job a free model does fine — especially a platform that hands the agent its own documentation over the same MCP connection. The screenshot above shows Big Pickle reading the full-stack-app guide before touching anything. It did not need frontier reasoning; it needed the manual, and the manual was a tool call away.

The safety half of the argument matters just as much when the model costs nothing. Handing backend credentials to a free stealth model sounds reckless. On Magic it is not, because safety is a property of the runtime, not the model: every operation runs inside role boundaries enforced at execution time, and the whitelisting system decides what generated code can bind to at all. The worst a bad generation produces is a failed execution — not an incident. If safety depended on the model's judgment, you would pay for the best judgment money buys. Because it does not, you are free to pay nothing.

The honest fine print

Free means free right now. Big Pickle is free for a limited time while OpenCode collects feedback, and its documentation says data from the free period may be used to improve the model — do not drive it with anything confidential, and assume the price eventually becomes a price. Rate limits exist, and stealth models get swapped and retired without ceremony.

I make no claim that Big Pickle matches Fable on hard reasoning, architecture discussion, or difficult debugging — it does not, and this build did not require it to.

The residual security list is the same as the last CRM: Magic's auth endpoint takes credentials as query parameters by documented design (HTTPS assumed), the JWT lives in localStorage (the standard SPA trade-off), and no penetration test was performed. The demo login above is a throwaway guest-role account on a demo cloudlet — that is why I can print it in a blog post.

What this actually demonstrates

It is tempting to read this as "free AI writes code," but the ledger is the real finding.

Four articles ago, the backend cost of an agentic build was a real line item. Then it was 3.4% of one. Then it was six cents. Now the agent is free, the platform is MIT-licensed open source, and the deliverable grew from a backend to a full stack. Both columns of the cost ledger read $0.00 — and the build got bigger.

When the platform owns the hard parts and the agent market races to free, the marginal cost of a secured, verified, deployed application stops being about money at all. What remains is judgment: the data model, the review, the decision of what to build. Those were always the parts worth a human's time. Now they are the only parts that cost anything.

Magic is MIT-licensed and open source — the repository is at github.com/polterguy/magic, with documentation at docs.ainiro.io.