Why we still say yes
We get the rescue calls. A founder builds something over a few weekends with an AI coding tool. It demos well. Then real customers turn up and it falls over. You might expect us to tell you never to do it.
We won't. For a lot of first versions, building it yourself is the right call, and we'd rather you did it well than not at all. What matters is knowing where the line is, and setting things up on day one so that crossing it means a handover instead of a rebuild.
This is what we tell friends who ask, whether or not they ever hire us.
When building it yourself makes sense
Some software carries a bigger risk than breaking. The risk is that nobody wants it. If that's where you are, spending months and a big budget on a polished build before anyone has used it is the expensive mistake. A rough version you made in a week is the cheap one.
The clearest case is validating demand. If you don't know yet whether customers will pay, put something in front of them. A version that does one thing badly but visibly will teach you more than a spec document.
Internal tools are another. If the only people using it are your own staff, and it replaces a spreadsheet or a shared inbox, it hardly matters that it's ugly or occasionally wrong. Your team will tell you when it breaks. Nobody outside the business sees it.
The same goes for something to show people. Investors, early customers, the co-founder you're trying to convince. A clickable thing that feels like the idea beats a slide deck, and it doesn't have to survive load or hostile users.
And there's the version you build to work out what you want. Most founders don't know until they've tried. A throwaway build surfaces the awkward questions early. What happens when a customer cancels halfway through? Who approves a refund? What does the admin screen need to show? Every one of those answers makes a later build cheaper.
In all of these cases the software exists to get you to a decision. Treat it that way and a few weekends is well spent.
Where it stops making sense
The line isn't about how big the app is. It's about who pays when it fails. Once a failure costs someone other than you something, the calculation changes.
Real customer data is the first trigger. Names, addresses, health details, anything a person would be upset to see leaked. Under the Privacy Act reforms a breach is reportable, and it can be costly. AI-generated code isn't careless on purpose, but it is careless by default, and it doesn't know which table holds the sensitive fields.
Payments are the second. Taking money means handling failed charges, refunds, disputes and receipts. Get any of those wrong and you have angry customers plus an awkward conversation with your payment provider. A lot of the rescue work we do starts here.
Anything regulated. Finance, health, education, legal. If a regulator or industry body has rules about how you store or process information, a prototype is a bad place to discover you've broken them.
More than a handful of users. Five friendly testers hide almost every scaling problem. Fifty real users on a Monday morning will find the slow query, the double booking, and the confirmation email that never sends.
Anything you can't afford to have down. If a day offline means lost revenue, missed appointments, or staff who can't work, the app needs monitoring, backups, and someone who understands it well enough to fix it at 7am.
None of these mean the code is bad. It might be fine. The problem is that nobody has checked, and the tools won't tell you. We wrote about what fixing vibe-coded software usually takes if you want to see what we find when we open one up.
Three things to do on day one
Whether a home-built MVP becomes a clean handover or a painful rebuild is mostly decided in the first hour. Three habits make the difference, and none of them need a developer.
- Keep it in a git repository you own. Git is the standard way to store code and its history. Most AI tools will set one up if you ask. What matters is that the repository sits in an account in your name or your company's, on a service like GitHub, and not only inside the tool you happen to be using. If the tool shuts down or changes its pricing, the code comes with you. A developer picking this up later will ask for it first. If the answer is a folder on your laptop, everything gets harder.
- Keep secrets out of the code. Your database password, your payment keys, your email credentials. AI tools like to paste these straight into the source. Ask the tool, in plain English, to put every secret in an environment file that stays out of the repository, and to tell you where that file lives. It takes a few minutes, and it means sharing the code with anyone, including us, doesn't also share the keys to your bank account.
- Write down what it's supposed to do as you go. Not formal documentation. A running plain-text note saying what each screen is for, what the rules are, and what you decided when the tool asked you a question. "Customers can cancel up to 24 hours before, after that they forfeit the deposit." "Admins see every booking, staff only see their own." The code will drift from what you meant, and this note is how anyone, including future you, can tell which one is right. It's the closest thing a founder can produce to what a discovery phase would hand a studio, and it turns a weeks-long handover into a meeting.
Decide when to stop before you start
The most expensive rescue jobs don't come from founders who built it themselves. They come from founders who kept going past the point where they should have stopped, because there was never a moment where the decision came up.
So pick the moment now, while it's cheap. Write it in the same note as everything else. It might be the first paying customer, or the tenth. It might be the first time you store something you wouldn't want on a billboard. It might be a date. Or it might be the third day in a row you've pasted an error into the chat window without understanding the answer.
When you hit it, the job isn't to throw the prototype away. The job is to have someone look at it and tell you what's worth keeping. Sometimes that's most of it. Sometimes it's the idea and the note and nothing else. Either way you're deciding with information instead of in a panic.
What a good handover looks like
When a founder brings us a prototype that followed the habits above, the first conversation is short. We read the note, look at the repository, and run it. Within a day or two we can say which parts are solid, which need rebuilding, and what it would cost to get to a version that can take real customers and real money. From there it's a normal build with a scope and a timeline. The founder has already done the most valuable part by finding out what the product is.
We build a lot of first products for early-stage companies through our SaaS and startup practice, and the ones that started as a founder-built prototype are often the best briefed. If you're at that stage, or you're approaching your tripwire and want a straight read on what you have, get in touch.
