If you run a business in the UK, you have probably had the message by now. Someone has seen your website or your spreadsheet-heavy process and offers to build you a custom app, in a fortnight, for a fraction of what software used to cost. Often they show you something on the first call that already looks the part.
That is not a bluff. Something genuinely has changed, and it is worth understanding what, before deciding what it means for you.
What has changed
AI building tools are powerful. Describe a screen, a form or a workflow in plain English and you can have working code in minutes. People call it "vibe coding": you steer by describing what you want, and the AI writes it. A single person can now produce in a week what used to take a small team a month or two, at least on the surface.
We are not about to tell you to avoid it. We use AI every day at Pixel & Shovel, for writing code, testing it, reviewing it and working through problems faster. It has made good teams quicker, and that saving should reach clients.
We use AI every day, but we are the architects of the build.
That distinction is the whole of this article. Generating code is now cheap. Deciding what the code should be, and taking responsibility for it once real customers and real data depend on it, is not.
What a demo hides
A demo is built to show the happy path: one user, clean test data, nothing going wrong. Most of the work in business software sits outside that path. These are the parts you will not see on the first call.
Security and logins
Who can sign in, what each person is allowed to see, how passwords are stored, what stops one customer viewing another customer's records. AI will happily generate a login screen. It will not reliably think through every way that screen can be got around, and it often leaves secret keys or open database settings in places they should never be.
Personal data and UK GDPR
The moment your app holds names, emails, addresses or anything more sensitive, you have legal duties under UK GDPR. Where is the data stored, and in which country? Who at the supplier can see it? Can you delete a person's records properly when they ask? Is it being sent to an AI service, and if so, is it used for training? We cover these questions in more depth in is your data safe with AI software?
Backups
Is there a backup, how often is it taken, where does it live, and has anyone ever actually restored from it? A backup nobody has tested is a hope, not a plan.
When it breaks at 9pm on a Friday
All software breaks at some point. A payment provider changes something, a server fills up, an update goes wrong. What matters is whether anyone notices before your customers do, whether there is someone to call, and whether they understand the system well enough to fix it calmly rather than prompting an AI and hoping.
Scaling beyond the demo
Something that runs nicely with ten test records can slow to a crawl with ten thousand real ones, or fall over when fifty people use it at once. Those limits are usually set by early decisions about how data is stored and fetched, and they are expensive to change later.
Integrations with real systems
Your business already runs on other things: accounting software, a payment provider, email, a booking system, perhaps a supplier feed. Connecting to those properly means handling failures, retries, duplicates and data that does not match. It is unglamorous work and it is where many quick builds come unstuck.
Code someone else can understand
AI can produce a lot of code very quickly, and it is not always tidy, consistent or explained. If the only way to change it is to keep prompting until it seems to work, every change becomes riskier than the last. Ask yourself whether another competent developer could pick it up and understand it.
Who supports it next year
Software needs looking after: security updates, new phone and browser versions, changes to the services it connects to, and the new features you will want once you have used it for a while. A low price for the build matters much less than who will still be there, and still understand it, in twelve months.
Generating code is not the same as architecting a system
The real work in a piece of business software happens before much code is written. It is a series of decisions, and AI can help with each one, but it cannot take responsibility for them.
- The data model. What a customer, a job, an order or a booking actually is in your business, and how they relate to each other. Get this right and everything else is easier. Get it wrong and every report and feature fights against it.
- What connects to what. Which system is the source of truth for each piece of information, and how it flows to everywhere else, so nothing is typed in twice.
- What must never fail. Taking payments, sending invoices, protecting personal data. Those parts get more care, more testing and more monitoring than the rest.
- What to build and what to buy. Plenty of problems are already solved by a well-made product. Building your own payments or email system rarely makes sense. Knowing where custom work earns its keep, and where it just adds something else to maintain, is judgement that comes from having done it before.
Without those decisions, you can end up with another standalone app on top of everything else, which is the pattern we wrote about in why another app rarely fixes the problem.
Questions to ask any supplier
These apply whoever is pitching you, us included. A good supplier will answer them plainly and will not mind putting the answers in writing.
- Show me something you built that has been live for a year. Not a demo. Something real people have relied on through updates, problems and changes.
- Who reviews the AI's code? Is an experienced person reading and testing what gets generated before it goes live, or does it ship as it comes out?
- How do you handle security and personal data? Where is it stored, who can access it, how is it backed up, and is any of it sent to AI services?
- What happens if you disappear? If the supplier stops trading or moves on, how do you get your data and code, and could someone else take it over?
- Do I own my data, and the custom code? You should own your data outright. On bespoke work, find out exactly what you own and what stays theirs.
- Who supports it after launch? A named person or team, how quickly they respond, and what it costs.
Vague answers to any of these are worth taking seriously, however impressive the demo.
How we work
We use AI for speed, and experienced people for the architecture, the security and the judgement calls. Every build starts with understanding how the business actually runs, and the code AI helps us write is reviewed and owned by people who understand the whole system.
We also build and run our own products, live in production: Jeanus, our CRM, Stamp for loyalty cards in Apple and Google Wallet, avibe for ticketing and bookings, and Strandline on the App Store. Running them day to day is how we learn what it takes to keep software secure, backed up and useful long after launch, and that carries into the work we do for clients.
Common questions
Is software built with AI tools bad?
No. AI building tools are genuinely useful and most good teams now use them. The risk is not the tool but the absence of experienced people deciding how the system should work, reviewing what the AI produces and taking responsibility for security, personal data and support once it is live.
What is vibe coding?
Vibe coding is building software by describing what you want to an AI tool in plain language and letting it write the code, often with little review of the code itself. It is a fast way to get something that works in a demo, but on its own it does not cover security, data protection, backups, integrations or long-term maintenance.
What should I ask a supplier who builds with AI?
Ask to see something they built that has been live for a year, who reviews the AI's code, how they handle security and personal data, what happens if they disappear, whether you own your data and the custom code, and who supports it after launch. Get the answers in writing.
Why does a cheap, fast build sometimes cost more in the end?
Because the build is only part of the cost. Fixing security gaps, rebuilding a data model that does not fit, untangling code nobody understands or recovering from a failure without a backup can cost far more than doing those things properly at the start.
If you have been offered a quick AI build and want a second opinion, or you would like to see what a properly joined-up setup could look like for your business, we are happy to help. Book a free 30 minute look at your systems, or ask for a free concept first.
