Cheap to Build, Expensive to Own: The Real Cost of Vibe-Coded Business Software

Something new is happening in small businesses. Owners who would never have called themselves technical are building their own software with AI. A CRM over a weekend. A booking system in an afternoon. A client portal that would once have cost tens of thousands and taken a development team months.

It is genuinely impressive, and we are not here to talk anyone out of it. We build software with AI ourselves, this platform included. What you can make in a few hours now would have been unthinkable a few years ago.

But building software and running software are two very different jobs. AI has made the first one dramatically easier. It has done very little to the second.

The demo is the easy part

When you vibe code something, you describe what you want, the AI writes it, and before long you have a screen that does the thing. You add a contact, it saves. You book a slot, it appears in the calendar. It works.

That moment feels like the finish line. It is closer to the start.

A working demo proves the software does what it should when everything goes right. A business system has to cope when things go wrong: when someone tries to break in, when a supplier changes something overnight, when the database fills up, when a customer does something nobody expected. Professional software companies spend most of their effort on exactly that, and they have teams, processes and infrastructure for it.

The average person building a CRM over a weekend is not thinking about half of it. They are thinking, quite reasonably, "look what I built for next to nothing".

So before your customers' names, details and payments go anywhere near it, here are the six questions worth answering.

1. Where is your customer data actually going?

A vibe-coded system often has more moving parts than its builder realises. Customer details might pass through the AI tool that generated the code, a hosted database, a form service, an email platform and a payment provider, each with its own terms and its own storage location.

Ask yourself: who can see this data? Where is it physically stored? How long is it kept, and can you delete it when a customer asks? If you are in the UK or dealing with customers in Europe, you need clear answers to these under GDPR, and "I'm not sure, the AI set it up" is not one of them.

2. What happens when one of your integrations changes?

To make everything work, your system might connect to five different platforms through their APIs. That is normal. It is also five points of failure you do not control.

Suppliers change their APIs, retire features, raise prices and have outages. Established software companies watch for this and update their integrations before customers notice. If you built it yourself, you are the one who finds out, usually when something has already stopped working.

3. Who fixes it at 9pm?

Picture a Thursday evening. Your booking page is down, customers cannot pay, and a client is messaging to ask why they cannot reach their files.

AI can help you write code. It cannot take responsibility for it. Someone has to understand the system well enough to diagnose the problem, fix it without breaking something else and get it back up quickly. If that person is you, be honest about whether you can, and whether you want to.

4. Has anyone tested it for security?

This is the one that worries us most. Code that works is not the same as code that is secure, and AI-generated code can look perfectly tidy while leaving a door open.

The questions to ask: has anyone tried to break it on purpose? Are the permissions set up so that one client cannot see another client's information, even if they change a number in the web address? Are passwords and secret keys kept out of places they should not be? Is everything served securely? Problems in this area rarely announce themselves. The system carries on working normally right up to the day someone takes advantage.

5. Can you actually get your data back?

If your database gets corrupted, a record is deleted by mistake or a service goes down, can you recover everything?

Having backups is not the same as being able to restore from them. The only way to know a backup works is to restore it and check. If you have never done that, assume you do not have a backup yet.

6. Who carries the liability?

If there is a data breach, telling your customers or the regulator "AI built it" will not reduce your responsibility. The business that collects the data is responsible for protecting it. The same goes for payments that go wrong, bookings that vanish or confidential documents that end up in the wrong hands.

And that is before you get to the ongoing work: software updates, security patches, performance as you grow, and the plain cost of keeping it all running.

Work out the cost of owning it, not building it

The real comparison is not "free to build" against "£X a month for established software". It is the total cost of owning each one over a year.

On the home-built side, add up the hours you will spend maintaining, fixing and updating it, the hosting and the services it depends on, and a realistic figure for what a day of downtime or a lost customer costs you. Then add the risk you would rather not think about: what a breach would cost in money, time and reputation.

Sometimes building your own still wins, especially for internal tools where a failure is an inconvenience rather than a crisis. For the systems at the heart of your business, the ones holding customer data and taking payments, it often does not.

Cheap to build does not always mean cheap to own. Sometimes the most expensive software is the software you thought you built for free.

A sensible way to use AI-built software

None of this is an argument against building with AI. It is an argument for being clear about what you have built.

• Prototype freely. AI is brilliant for trying ideas, testing a workflow and working out what you actually need before you pay for anything.
• Build internal tools with care. A tool your team uses internally, with no customer data and no payments, is a good place to start.
• Get help before it goes live. If it will hold customer data or take money, have someone experienced review the security, permissions, backups and hosting first.
• Decide who owns it. Name the person responsible for keeping it running, and what happens when they are not around.
• Write down what it does with data. If you cannot explain where the data goes, you cannot protect it. A short AI use policy for your team is a good place to set the rules.

The skill underneath all of this is knowing when to trust what AI gives you and when to check it. That is exactly what our course Know When to Trust What AI Tells You is about, and it applies to code as much as it applies to research or copy.

AI has made it easier than ever to create software. It has not removed the responsibility of running it properly. When real customers, real data and real money are involved, that is a distinction worth taking seriously.