The app in the screenshots below took 7 minutes to build.
Not a mockup. A login screen backed by JWT authentication, a client manager reading and writing through a role-secured CRUD API, and an Emails tab that dispatches real messages over SMTP. The backend was produced by wrapping a database in generated CRUD endpoints, plus one English sentence handed to the Hyperlambda Generator for the send-email endpoint.
I have published the receipts for builds like this before, so this article is not another ledger.
It is about the part of those 7 minutes that usually gets lost.
The database was the boring part
Nothing in the build depended on the database being new.
The CRUD generator does not care where a schema came from. It reads metadata — tables, columns, types, keys — and every Microsoft SQL Server database on earth exposes exactly that. The database in this demo was created seconds before the endpoints were. Yours carries twenty years of history, three generations of developers, and foreign keys that encode how your business actually works.
Same metadata. Same generator. Same 7 minutes.
That is the entire point. The demos always run on fresh databases because demos need reproducibility — but the machinery only ever sees the schema, and your ERP on SQL Server has a better schema than any demo. The hard part of a full stack app — modelling the business correctly — is the part you finished years ago.
What got built
The front door. JWT authentication against the platform's built-in auth — no auth library, no password hashing code, no session plumbing anywhere in the app.
The client manager. Search, add, edit, delete, and per-client notes — every operation travelling through generated CRUD endpoints, each one gated on a role before any logic runs.
And the one endpoint that is not a table projection: composing an email to a client, dispatched through the platform's SMTP integration. That endpoint was described in a single English sentence and generated in seconds — the application never saw a mail-provider credential, because there is none in the application.
The recipe
Four moves.
Connect the database. Magic speaks to SQL Server through the standard .NET data provider — it is one more client, nothing installed inside the database, no schema changes.
Wrap the tables. The CRUD generator reads the schema and emits endpoints — read, create, update, delete, count — with authentication and role-based access control already wired in.
Describe what CRUD cannot do. "Look up this client's email address and send them a message" is one sentence, and the Hyperlambda Generator turns it into a working, role-gated endpoint.
Serve the frontend. The same system that serves the API serves static files, so the app's HTML, CSS and JavaScript went live the moment they were written. One host, no CORS, no separate deployment.
The full walkthrough — scoped database users, read-only starts, connecting an agent over MCP — is its own article: Create an AI Agent From Your SQL Server or MySQL Database, Step by Step.
No agent required
This build ran through an AI agent over MCP, but the CRUD wrap does not need one. The dashboard's Backend Generator does the same thing point-and-click: pick the database, tick the tables, choose which roles may call what, and click Generate.
Same generated endpoints, same enforcement, no conversation required. The agent is a convenience, not a dependency.
"But my database is legacy"
Legacy means load-bearing, not obsolete — I have made that argument at length in Supabase for SQL Server and MySQL, so here is the short version.
You connect through a scoped database user, so the platform can never do more than the credentials the DBA granted. You can start read-only, which turns "what if something writes the wrong thing" into a non-question for day one. And the whole stack runs in two containers you place yourself — same rack, same VLAN, same firewall the auditors already approved. The database does not change, and the data does not leave.
The fine print
Seven minutes was measured for this schema, at this size. Your 200-table ERP will take longer — but the added time goes into decisions, not code: which tables deserve exposure, which operations each table gets, which roles may call them. Those are judgment calls a DBA is already equipped to make, and they were never the expensive part.
The frontend is where human taste still spends its time. Generated backends are uniform; good interfaces are not.
And writes deserve the same respect they have always deserved. Start read-only, prove the surface, then grant writes table by table. The speed changes nothing about the discipline.
The question worth asking
The question is no longer whether your organisation can afford to modernise the systems built on SQL Server. It is whether wrapping one of them in a secured API and a working app is still a project at all — or just an afternoon.
Magic is MIT-licensed and open source at github.com/polterguy/magic, with documentation at docs.ainiro.io.
Top comments (0)