Vibe coding for UK small businesses: the house rules that stop it going wrong

Short answer: you can now build a useful internal tool by describing it to an AI assistant, and a small business should. But the speed is the risk. A handful of house rules, written down before you start, is the difference between a tool that saves you an afternoon a week and one that quietly emails the wrong customer.

What “vibe coding” actually means

The term was coined by Andrej Karpathy in February 2025 for a style of building where you describe what you want, accept what the AI writes, and stop looking at the code at all. Simon Willison drew a useful line soon after: if you review the code and understand it, that is AI-assisted programming, not vibe coding. Both are worth doing. They suit different jobs.

For a small business the honest version is somewhere in between. You probably won’t read every line. You can still insist on knowing what the thing does, what it can touch and how you would switch it off.

Where it earns its keep

Internal tools nobody sells. A page that tidies a supplier’s price file into the shape your system wants. A script that renames last month’s scanned receipts. A dashboard that reads two spreadsheets and tells you which jobs haven’t been invoiced.

Prototypes. A rough version of the tool you were about to pay an agency for, so that when you do talk to someone, you are describing something real.

One-off jobs. The migration you do once and never again.

What these have in common: if they are wrong, you find out quickly, and nobody outside the business is hurt.

Where it doesn’t, without a review

Anything that takes payments, anything that stores customers’ personal data, and anything that writes to a live system such as your accounts, your order management or your website’s checkout. Those are the places where a confident mistake costs real money or breaks the law. Build them if you like, but have someone who can read the code look at them before they go live.

Ten house rules

1. Start read-only. The first version of any tool should only look at data. Once you trust what it reads, consider letting it change things, and even then preview each change before it happens.

2. Keep personal data out until it’s reviewed. The moment a tool handles customer names, emails or addresses, UK GDPR applies to it, just as it applies to the rest of your business. If you handle personal information you will usually need to pay the ICO data protection fee anyway. Test with made-up data.

3. No secrets in the code or the chat. API keys, passwords and tokens go in the hosting platform’s secret store, never in a file and never pasted into a prompt. If one ever ends up in a file you have shared or committed, treat it as leaked and replace it.

4. Use version control from day one. Even if it is just you. Being able to see what changed yesterday, and undo it, is most of what keeps a vibe-coded tool alive.

5. One change at a time. Ask for one thing, check it works, keep it, then ask for the next. Five changes in one request means that when something breaks you won’t know which one did it.

6. “Tested” means you saw it. Ask the assistant to write tests, then run them yourself and keep the output. An AI saying “this should work” is a prediction, not a result.

7. Preview before anything writes. If a tool changes prices, sends emails or creates orders, it should show you exactly what it is about to do and wait for a yes.

8. Know where it runs and what it costs. Write down which account it is deployed to and who pays for it. Free tiers have limits, and a forgotten tool running on a personal card is a common surprise.

9. Write down what it does. Three lines in a README: what it is for, what it can touch, how to turn it off. Future you will be grateful.

10. Name an owner. One person who notices when it breaks. Software with no owner doesn’t stay working.

The security basics still apply

Code that works is not the same as code that is safe. Before anything faces the internet, check it against the well-known failure list in the OWASP Top Ten, or ask the assistant to review its own work against it. The NCSC’s small organisations guide covers the surrounding basics: backups, passwords and devices.

How we do it

We build Grafto’s own tools this way, under written house rules. Every change goes through a reviewed pull request, no keys go in the code, and “tested” means the command and its output are pasted into the change, not asserted. That is less glamorous than the demos, and it is why the tools are still running.

When to stop and pay someone

When the tool starts taking money, holding customer records at scale, or becoming something the business can’t operate without. At that point you don’t need to throw it away: you need someone to read it, harden it and take responsibility for it. The prototype will make that conversation shorter and cheaper.

If you are not sure which of your jobs are worth building a tool for at all, start with which jobs AI is genuinely good at, or let the AI Tools Report work it out from your own week.

Sources

• Simon Willison, “Not all AI-assisted programming is vibe coding” (19 March 2025)
• OWASP Top Ten
• NCSC, Small organisations guide to cyber security
• ICO, Data protection fee
• ICO, Guidance on AI and data protection

Questions, or want a tool we don't have yet? Email hello@grafto.co.uk — a real person replies.