Prototype to Production

Your AI-built prototype works in the demo. We turn it into software that holds real users, real data and real money: auth, migrations, tests, and a deploy you can trust.

Book a call ↗

4.9 on Clutch, 6 reviews4 international awards since 2022Building from Budapest since 2021

Code under test, the work that turns a prototype into production software

The demo works. That is exactly the problem.

You described a product to Lovable, v0, Bolt, Replit or Cursor and something real came out. It has screens, it has a login, it does the thing. You have shown it to people and they liked it.

So you did the sensible thing and tried to launch it, and discovered that the distance between works in the demo and works for paying customers is most of the project.

This is not a failure of the tools, and it is not a failure of yours. These tools are extraordinarily good at producing the version that convinces someone. They are optimised for exactly that, and the code they generate reflects it: the shortest path to a screen that behaves. None of the work that makes software safe to depend on is on that path, because none of it is visible in a demo.

What is usually missing

After enough of these, the list barely changes:

Authorisation that exists only in the browser. The demo hides the admin button from non-admins, and the endpoint behind it will happily answer anyone who calls it directly. This is the single most common finding.

Database rules left wide open. Row-level security disabled, or a policy of true, because that was the fastest way to make the prototype work. Every user can read every other user's data.

Secrets in client-side code. API keys and service tokens shipped to the browser, where they are one right-click from being extracted and used on your account.

Queries that only work at demo scale. One query per row instead of one per page, no indexes, lists that fetch the entire table and filter in JavaScript. Fine at ten records. Unusable at ten thousand.

No migrations. The schema lives in whatever state the last prompt left it in. There is no way to change it without risking the data, and no way to know what production actually looks like.

Error handling that assumes success. Payment fails, upload times out, third-party API returns a 500, and the interface either lies or hangs. The demo never exercised these paths because the demo never failed.

No tests and no pipeline. Every change is a hope. This is why velocity collapses about three weeks after launch: each fix has a decent chance of breaking something else, and there is nothing to catch it.

How we work through it

Audit first, fixed scope. Five days, and you get a written account of what is there: sound parts, demo-shaped parts, security holes, and what each fix costs. No code is written yet. If you take that document and hire somebody cheaper, it has still done its job.

Then the security and data work, before anything cosmetic. Auth moves to the server, database rules get written and tested, secrets move out of the client. This is first because it is the only category where waiting has a cost that compounds. Every day of real traffic on an open database is a day of exposure you cannot take back.

Then load, then tests, then the deploy. In that order, because each one depends on the last being true.

We keep what is worth keeping. Usually that is most of the interface and much of the product logic: real work, genuinely done, and rewriting it out of tidiness would be us billing you for our own preferences. What tends to get replaced is the layer underneath: data access, auth, anything that talks to money.

What you should expect from us

We will tell you what we find, including when it is worse than you hoped. We will tell you when a rewrite is cheaper than a rescue, even though the rescue is the easier thing for us to sell. And we will hand it back documented, so that keeping us is a decision rather than a dependency.

We have been building this way since 2021: MVPs, web and mobile apps, and AI features that have to work when the demo is over. This service exists because the same conversation kept happening: someone had built something genuinely promising with AI tooling, and needed it to become software.

If that is where you are, send us the repository and the URL. The audit will tell you where you actually stand.

How it works

A five-day audit before anyone writes code: We read the whole codebase, run it against realistic data, and try to break it the way a real user or an attacker would. You get a written account of what is actually there: which parts are sound, which are a demo pretending to be a feature, where the data can leak, and what it would take to fix each one. It is a fixed scope and it is useful even if you then hire somebody else. The point is that you stop guessing about your own product.
Locking the doors nobody built: This is the most common finding and the most expensive to ignore. AI-generated apps routinely ship with authorisation checked in the browser rather than on the server, database rules left open because that was the fastest way to make the demo work, and API keys sitting in client-side code where anyone can read them. Every one of those is invisible in a demo and every one of them is a breach the first week you have real users. We close them and we show you the before and after.
Making it survive a real load: Prototypes are built against ten rows and fall over at ten thousand. We find the queries that run once per item instead of once per page, add the indexes nobody needed at demo size, put real pagination behind lists that currently fetch everything, and move slow work out of the request. Then we load-test it, so the number we give you is measured rather than hoped for.
Migrations, so your data stops being disposable: A demo can be reset when the schema changes. A product cannot. We put your database under version-controlled migrations, add backups you have actually restored from once in front of us, and separate staging from production so a mistake stops being permanent. This is unglamorous and it is the difference between a product and a prototype.
Enough tests that changes stop breaking things: Not a coverage target; those buy nothing. Tests around the paths that cost you money if they break: signing up, paying, the two or three actions your product exists to perform. Plus a pipeline that runs them on every change and refuses to deploy if they fail. The goal is narrow and specific: you should be able to ship on a Friday.
Yours to keep, or ours to run: We can hand it back with the documentation your team needs to own it, or keep running it on a monthly basis. Both are real options and we will tell you which one we think fits. What we will not do is leave you dependent on us by accident.
And when the honest answer is to start again: Sometimes it is. If the fastest route to something you can build on is a rewrite of a component, occasionally of the whole thing, we say so in the audit, with the reasoning and the cost, before you have spent anything on hardening the wrong foundation. We would rather lose the larger project than sell you a rescue that cannot work.

What is and is not included

Included

A five-day audit with a written, prioritised findings document
Authorisation moved to the server and tested
Database rules written, tested, and shown to you before and after
Secrets out of client code, rotated where they were exposed
Load testing with measured numbers rather than estimates
Version-controlled migrations, backups, and a staging environment
Tests on signup, payment and your two or three core actions, plus CI

Not included

New features, which are quoted separately after the audit
Redesign, unless the audit finds the interface is the problem
Ongoing hosting and third-party service costs
Continuing to build in the AI tool afterwards, which we will advise against

What we build it with

Next.js
React
TypeScript
PostgreSQL
Supabase
Stripe
Playwright
Docker

Questions

The things people ask first.

What does the audit cost, and what do I get?

Five days, fixed scope, and you get a written account of what is actually in the codebase: which parts are sound, which are a demo pretending to be a feature, where data can leak, and what each fix would cost. It is useful even if you then hire somebody cheaper, which is deliberate.

What is usually wrong with an AI-built app?

The same list nearly every time. Authorisation checked in the browser rather than on the server. Database rules left open because that was fastest. API keys shipped to the client. Queries that work at ten rows and fall over at ten thousand. No migrations, no tests, no pipeline. Every one is invisible in a demo.

How long does hardening take?

Typically three to eight weeks after the audit, depending on what it found. Security and data work first, because that is the only category where waiting has a cost that compounds: every day of real traffic on an open database is exposure you cannot take back.

Will you throw away my code?

Usually not. Most of the interface and much of the product logic is real work, genuinely done, and rewriting it out of tidiness would be billing you for our preferences. What tends to get replaced is the layer underneath: data access, auth, anything that touches money.

What if a rewrite really is cheaper?

Then the audit says so, with the reasoning and the cost, before you have spent anything hardening the wrong foundation. We would rather lose the larger project than sell a rescue that cannot work.

Which tools do you work with?

Lovable, v0, Bolt, Replit and Cursor output, and anything else that produced a working React or Next.js application. The tool matters less than what it left behind.

Also in Build

Tell us what you are trying to ship.

Start a conversation ↗