A founder builds a working version of their idea in a weekend with Cursor, Lovable or v0. It runs. It looks right. It demos well enough to show an investor or a first customer. Then they try to ship it, and the afternoon's progress turns into a month of problems that only appear once real people and real data arrive. The tools aren't failing. The last part of the job, the part that was always the hard part, got skipped because the demo already looked done.
Where these builds break
The same faults turn up across the rescue projects we take on. The tools optimise for a working screen, not a system that holds.
- Security is an afterthought. API keys and secrets sitting in the browser where anyone can read them. Database access with no rules, so any visitor can read or delete any record. Admin routes that check nothing.
- Authentication is faked. A login form that looks real but stores the logged-in state somewhere a user can flip it themselves. Password handling that wouldn't pass a five-minute review.
- The data model doesn't survive contact. Structures that work for the three sample records in the demo and fall apart at three thousand, or when two people save at once.
- Nothing handles failure. The happy path works. A declined card, a dropped connection, a duplicate submission, an empty result: nobody considered them. So the app breaks or, worse, silently loses data.
- No tests, so no way to change anything safely. Every edit risks breaking something elsewhere, and nothing catches it.
- Dependency and code sprawl. The same problem solved three ways in three files. A long list of packages, some abandoned, pulled in for problems a few lines would have handled.
- No deployment story. It runs on the founder's laptop. Getting it onto a real server, with environment variables, a database and a domain, is its own project. Nobody has started it.
Why the last twenty percent is the hard part
The demo is the well-understood eighty percent: the screens, the obvious flow, the parts a model has seen a thousand examples of. The other twenty percent is specific to your case and unforgiving in the detail. It's most of the actual effort. Edge cases. Security. What the system does when something goes wrong. The load it has to carry. The plumbing to payments, email and whatever else it needs to talk to. A model is weakest exactly here, because this part runs on judgement and context, not pattern.
The trap is that the eighty percent looks like the whole thing. It feels almost finished, so everyone underestimates what's left. Including the person who built it.
How we take one over
We don't throw the work away and start again. Starting over wastes what's useful in the prototype: proof that the idea works, and decisions already made about how it should feel. Instead we run it through three stages.
- Audit. We read the whole codebase and give you a written account of what you're sitting on. What's safe, what's exposed, what won't scale, and what each fix will take. You get this whether or not you go further, so at minimum you know the real state of the thing.
- Stabilise. We close the urgent holes first (the exposed keys, the open database, the broken authentication) so the project is safe to keep running while the rest of the work happens. If it's already live and leaking, this jumps the queue.
- Finish. We rebuild the parts that need it, add error handling and tests, sort out the data model, and deploy it properly on infrastructure you own. You end up with code a senior developer has read and is prepared to support. Not a generated draft nobody has checked.
That last point is the same standard we apply to work we start from scratch. We describe it in how we use AI without shipping slop. AI in the loop, a person accountable for the output.
What you keep
Everything we finish lives in your accounts: your hosting, your domain, your repository, your platform. It's documented so any competent developer could pick it up. Lock-in is a business model, and it isn't ours. If the project needs to connect to other systems (an ERP, an accounting package, a payment provider), that's integration work we scope as part of finishing it. If the idea grows into something bigger, it becomes a proper custom web app, not a patched prototype.
If your build made it most of the way and stalled, the Vibe-Code Rescue page explains how the audit works and what it costs. If it's already live and exposed, call rather than email. Those go to the front.