A founder builds a working version of their idea in a weekend with Cursor, Lovable or v0. It runs, it looks right, and 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 do not show up until real people and real data arrive. This is not a failing of the tools. It is what happens when the last part of the job, the part that was always the hard part, gets skipped because the demo already looked done.
Where these builds break
Across the rescue projects we take on, the same faults turn up, because the tools optimise for a working screen rather than 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 in a way a user can flip themselves. Password handling that would not pass a five-minute review.
- The data model does not 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, none of these were considered, 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 there is nothing to catch it.
- Dependency and code sprawl. The same problem solved three different ways in three files, and a long list of packages, some abandoned, pulled in to solve problems that 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 that was never started.
Why the last twenty percent is the hard part
The demo represents the well-understood eighty percent: the screens, the obvious flow, the parts a model has seen a thousand examples of. The remaining twenty percent is the work that is specific to your case and unforgiving in detail, and it is most of the actual effort. It is the edge cases, the security, the way the system behaves when something goes wrong, the load it has to carry, and the plumbing that connects it to payments, email and whatever else it needs to talk to. A model is weakest exactly here, because this part depends on judgement and context rather than pattern.
The trap is that the eighty percent looks like the whole thing. Progress feels almost finished, so the remaining work gets underestimated by everyone, including the person who built it.
How we take one over
We do not throw the work away and start again. Starting over wastes what is genuinely useful in the prototype, the proof that the idea works and the 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 are sitting on: what is safe, what is exposed, what will not scale, and what it will take to fix each. 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 is already live and leaking, this jumps the queue.
- Finish. We rebuild the parts that need it, add the error handling and tests, sort out the data model, and get it deployed properly on infrastructure you own. The result is 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, which we describe 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 is documented so any competent developer could pick it up, because lock-in is a business model and it is not ours. If the project needs to connect to other systems, an ERP, an accounting package, a payment provider, that is integration work we scope as part of finishing it, and if the idea grows into something larger it becomes a proper custom web app rather than a patched prototype.
If you have a build that got most of the way and then stalled, the vibe coding completions page explains how the audit works and what it costs. For anything already live and exposed, call rather than email, because those move to the front.