A new kind of enquiry
Over the last year a new type of project has started turning up in our inbox. Someone has built an app themselves, or had a contractor knock it together in a weekend, using one of the AI app builders (Lovable, Bolt, Replit and their peers) or a long back-and-forth with an AI coding assistant. It looked great. It demoed well to a business partner or an investor. Then real customers arrived and it started falling over.
The email usually says something like "it works but it's unreliable", or "we can't add the next feature without breaking something", or "we have paying users and I'm scared to touch it".
We don't sneer at these. The tools are impressive, and whoever built the prototype has done something useful: they've worked out exactly what they want. What follows is what we find when we open one up, how we decide what to do with it, and what a fair assessment looks like.
What we find on first look
Every codebase is different, but vibe-coded ones share a family resemblance. The tool was optimising for "make it work right now" and nobody asked it to think about "make it keep working". So we tend to see the same things.
- No tests. Nothing checks that what worked yesterday still works today. Every change is a guess, which is why the owner is scared to touch it.
- Secrets in the browser. API keys for the payment provider, the email service or the AI model sitting in front-end code, where anyone who opens developer tools can read them. This one is common and it's urgent.
- No boundary around who can do what. Login was added because a tutorial said to. The part that stops one customer reading another customer's data is thin or missing.
- One enormous file. Or a handful of them, thousands of lines each, because the tool kept appending to whatever it touched last.
- Trial and personal accounts everywhere. The email provider is on a free tier that stops at a few hundred sends. The database is on someone's personal login. The domain renews to a card nobody checks.
- Error handling that hides errors. Failures are swallowed so the demo never showed a red screen. In production, a customer's order silently doesn't go through and nobody finds out.
We also often find the schema was changed by hand with no record of how, so the database can't be rebuilt anywhere else. And pricing rules or eligibility checks living inside the text sent to an AI model, so the app behaves a little differently every time and nobody can point to where the rule lives.
None of this is new. It's the same set of problems we've been fixing in cheap and rushed builds for years, arriving faster and in bigger numbers. We wrote about that pattern in the true cost of a cheap website, and most of it applies here word for word.
How we triage it
Before anyone writes code we spend a short, fixed block of time working out what exists. Most owners have never seen this done, because the person who built the prototype never had a reason to.
We ask for read access to the code, the hosting, the database and every third-party service the app talks to. If access can't be found for something, that's a finding in itself. Then we work through security, data, reliability, cost and how hard the thing is to change.
Security comes first because it's the one that can hurt you tomorrow. Exposed keys get rotated on the spot. Obvious holes in who can see what get closed. If the app holds customer details, we check it against what the Privacy Act reforms now expect of a business your size.
After that we look at whether the database can be rebuilt from something written down. What happens when the payment provider is slow, or two customers do the same thing at once. Which free tier is about to become a bill or a hard stop. And how much of the code someone who didn't write it can follow.
You get a written assessment out of this: a plain list of what we found, ranked by how much it matters, with a recommendation at the end. You can take it to us or to anyone else.
The three ways it usually goes
Almost every rescue lands in one of three places. Which one depends less on how messy the code is and more on how much of the business now runs on it.
The first is to stabilise it and keep it. The prototype is basically sound, the problems are concentrated in a few spots, and the owner needs it to stop breaking more than they need it to grow. We fix the urgent security issues, add enough tests around the core paths to make changes safe, move the secrets and services onto proper accounts, and set up monitoring so failures get noticed. The code stays recognisably the same. This is the cheapest path, and it's the right one more often than people expect.
The second is a partial rebuild around the parts worth keeping. Usually the screens and the data model are fine and the logic underneath is a tangle. We draw a clear boundary, rebuild what's behind it, and leave the rest alone until there's a reason to touch it. This is the most common outcome for anything with real customers and a roadmap.
The third is to rebuild from the spec the prototype wrote. Sometimes the prototype was a good way to find out what to build and a bad way to build it. When that's the case, the owner has already done the hardest part of any software project. They have a working, clickable definition of what they want, refined against real users, which is a better brief than most discovery phases produce. We rebuild it on a foundation designed to last, and it usually goes faster than the original did because there's nothing left to guess about.
How to tell which one you're in
You don't need to read code to get a rough sense of where you stand.
If there are no paying customers yet and the problems are mostly "it looks unfinished", you're probably in stabilise territory, or you should keep going yourself for a while. If money is flowing through it and you've already had an incident that cost you a sale or an apology, you're somewhere between stabilise and partial rebuild. If every new feature takes longer than the last, and the last one broke two things you didn't touch, the core has stopped being changeable and you're looking at a partial or full rebuild.
One signal overrides all of that: exposed credentials, or customer data that other customers can reach. That gets fixed this week whatever else happens.
What a fair assessment looks like
We've seen the other kind. An agency looks at the app for ten minutes, declares it all rubbish, and quotes a full rebuild at a number that makes the owner feel foolish for ever trying. That's a pitch, not an assessment.
A fair one tells you what's fine, because some of it always is. It ranks problems by consequence rather than by how offended a developer is about the code style. It gives you at least two options with real trade-offs instead of one big number. And it separates what can hurt you tomorrow from what can wait, so you can deal with the first without committing to a six-month plan today.
Building a working prototype of your own product is what a good founder does. The gap between that and something that runs a business is real, but it's a known gap, and closing it is ordinary work for a studio that builds custom software for a living.
If you've got an app that worked as a demo and is now struggling with real customers, send us the address and a sentence about what it does. We'll look at it and tell you plainly where it stands. Get in touch.
