What vibe coding cannot do

Regulated decisions where being wrong costs money

If the software decides something a regulator can fine you for — a tax treatment, a payroll figure, a medical or legal determination — do not have it decide. Have it record, prompt and route, and leave the decision with a person.

The failure here is not that the system is often wrong. It is that when it is wrong you cannot tell, and the liability is yours regardless. A system that quietly applies the wrong VAT treatment to four hundred invoices is worse than no system, because it produces confident, consistent, auditable errors.

The version that does work is narrower and genuinely useful: the software holds the records, flags what needs attention, enforces the deadline, and puts the decision in front of the person whose signature it is. That is most of the value and none of the exposure.

Deep integration with legacy accounting software

If the plan depends on reading and writing live into a desktop accounting package installed on one machine in the office, this will not work. Those systems mostly have no interface to connect to, and the ones that do charge for it.

Be specific about what you actually need before you rule anything out, because "integration" covers two very different things. A nightly export and import — a file out of one, a file into the other — is usually fine and solves most of the real problem. Live two-way synchronisation, where a change in either system appears immediately in the other, usually is not.

If the answer has to be the second one, you need a developer with access to that specific package, and you need the vendor to be willing. That is a different project with a different budget, and no amount of describing it well changes that.

Heavy concurrent load

Internal tools for a company of five to a hundred people are what this is built for. A public system where thousands of people press the same button in the same second is a different engineering problem.

The distinction that matters is not visitor numbers, it is contention: how many people are competing for the same record at the same moment. Two hundred staff using an internal system all day is comfortable. Two thousand customers trying to claim the last forty places at nine o'clock sharp is not, and it fails in ways that are unpleasant to debug and easy to get wrong.

If your thing is a ticket release, a public registration deadline or a flash sale, that is the part to hand to someone who does it for a living, even if everything around it is built here.

Anything nobody in the company can describe

This is the most common failure and it has nothing to do with software. If three people describe the process three different ways, the system will faithfully build one of the three, and it will be blamed for the disagreement.

It is worth being blunt about how this looks from the inside, because it does not look like a disagreement. It looks like the system being wrong. The sales manager says quotes are approved before they go out; the person who actually sends them says that only happens above a certain value; the owner believes both. Nobody is lying. The rule was never written down, and now it has been written down wrong.

The fix is not technical and it is not expensive. Before you describe anything to any tool, get the three people in one room and write the rule on one page, including what happens in the awkward case. If you cannot get to one page, that is the finding — and it was true before you went looking for software.

What still works in these cases

Usually a narrower version of the same idea. Take the decision out and keep the record-keeping, take the live sync out and keep the nightly file, take the peak out and keep the everyday.

• Regulated work: the register, the deadlines and the reminders here; the decision stays with the person who signs
• Legacy accounting: an export and import on a schedule, rather than a live connection
• Peak load: the internal side here, the public spike handled by something built for it
• Undescribed processes: nothing, until the page exists. Then everything

If this is you, do not buy it

If your project sits squarely in one of the first three and cannot be narrowed, hire a developer or an agency. That is the cheaper answer and we would rather say it now.

We sell plans from €29 a month and a build service between €1,200 and €3,500. Neither is worth buying for a project that will fail for a reason that was visible before you started. If you are not sure which side of the line you are on, the fourth section above is the one to reread — it is the one that decides it more often than the other three combined.