Vibe coding or hire a developer: which does your idea actually need?

We get asked this most weeks, usually by someone who has already built something over a weekend and is trying to work out whether to keep going alone. The answer is genuinely "it depends", but not in the evasive way agencies usually mean it. It depends on four things you can check yourself in about ten minutes.

The four questions

Ask them in this order. The first one that gets an uncomfortable answer is your answer.

• Does it hold anyone’s data but yours? The moment a second user exists, somebody has to decide who can see which record. That is authorisation, it is the single most common hole in generated code, and getting it wrong is a breach rather than a bug.
• Does money move through it? Payments fail halfway. Cards get declined after the order is written. Webhooks arrive twice. None of that is in the happy path a prompt produces, and all of it produces silent corruption.
• Is it regulated? Health, financial or legal data brings obligations that no coding tool knows your jurisdiction has.
• Will it still be here in a year? Software you intend to keep needs to be changeable. Software for a one-off campaign does not.

Four noes and you should carry on building it yourself. We mean that — you do not need us, and hiring anyone at that stage is a way of spending money to feel serious.

Where vibe coding is genuinely the right call

Internal tools with a handful of trusted users. Prototypes built to be shown and then thrown away. Landing pages and campaign microsites. Anything where the worst realistic outcome is that it breaks and somebody reruns it.

In all of those, the thing AI tools are bad at — the consequences of being wrong — barely applies. You get most of the value at a fraction of the cost, and the honest advice is to take it.

Where it stops being the right call

The moment other people’s data or money is involved, the calculation inverts. Not because the code is worse — often it reads fine — but because the failures stop being visible. A broken layout announces itself. A missing authorisation check does not announce anything at all, until it does, publicly.

The failures that matter in production are the ones nothing tells you about.

This is also why "it works" is a weak signal at this stage. Of course it works; you have tested it as the only user, with valid data, on a good connection, while nothing failed. Production is none of those things.

The middle path most people actually want

The framing of "build it myself or hand it to an agency" is a false choice, and it is the expensive one. Both extremes waste something: doing it alone risks a rebuild, and handing it over throws away the speed that got you here.

What works better is keeping the tools and adding an engineer to the specific decisions that are expensive to reverse. In practice that is a small list: how the data is shaped, who is allowed to see what, where the secrets live, and what happens when something half-fails. Four conversations, not a rebuild. Everything else you can genuinely keep doing yourself.

What it costs to get this wrong

Getting it wrong in the cautious direction costs you money and some speed. Getting it wrong in the other direction costs you a rebuild — and rebuilds are expensive less because of the code than because they happen at the worst possible time, once you have users, a deadline and someone asking why the thing that worked last month cannot be changed.

So the asymmetry is the argument. If you genuinely cannot tell which side you are on, assume you are on the side that needs the review. It is the cheaper mistake.