Can I build my business app with AI?

Short answer: yes, you can build something. Probably this week, possibly this afternoon, and it will look finished.

Whether it is a business app is a different question, and the companies selling the tools are more honest about that than most of the people selling courses on them.

I write a lot of my own code with an AI assistant now. I use Claude Code most working days, and I have written here about what that looks like when it goes slightly wrong. So this is not a post about AI being a fad. It is about the gap between the demo and the thing you can safely put your customers’ data into.

What the tools are genuinely good at

Getting from nothing to a screen you can click on. Describe a booking form, a job tracker or a customer list in plain English, and Lovable, Replit, Bolt or Claude Code will produce a working interface with a database behind it faster than I can write the scoping notes.

The NCSC, which is not an organisation given to hype, published a blog on 24 March 2026 called “Vibe check: AI may replace SaaS (but not for a while)”. Its author, Dave Chismon, describes a startup whose SaaS renewal quote doubled, so one of their engineers built a replacement with the core features in a couple of hours. His line is that the cost and effort curve for “bespoke enough” software is shifting. I agree with him. A prototype that used to be a week of my time is now an evening of yours.

The same blog has the sentence you should read twice. For someone with little or no technical experience, the tools create code they never could, “but it’s often unreliable, hard to maintain, or has critical issues”.

What the tool makers say is still your job

Read the security page of any of these products and the tone changes.

Lovable’s documentation says it plainly: “You are responsible for ensuring that your app meets the security requirements appropriate for its use case.” Its scanners, it says, “cannot guarantee complete security”, and for anything handling sensitive data it suggests a professional review.

That was written after something. In May 2025 a vulnerability was published against Lovable, CVE-2025-48757: generated sites with weak row-level security let unauthenticated visitors read or write arbitrary database tables. Lovable disputes the record, and the reason it gives is the interesting part. According to the NVD entry, each customer “accepts a responsibility over protecting the data of their application”.

Whatever you think of that argument, it tells you where the liability sits. With the person who pressed publish.

Row-level security is the rule in the database that says Customer A can only see Customer A’s rows. Supabase, the database a lot of these builders sit on, puts it in a red box in its own docs: a table in an exposed schema without it “is readable and writable by any role with a grant on it”. Lovable now scans for missing or wide-open rules every time you publish, and its deep scan looks for users who can see data that isn’t theirs. That’s the right question. It’s also one only you can fully answer, because the scanner doesn’t know that your cleaners should see today’s jobs and not the client’s invoices.

This is the same problem I build around deliberately on real projects. On one client portal I gave every client company its own database file so that a query that forgets its filter has nowhere to leak to. And even with that care, I once found one permission check guarding two unrelated powers. Access control is where the quiet bugs live, in code a human reviewed.

The database is the part that bites

In July 2025 SaaStr’s founder, Jason Lemkin, was building an app in public with Replit’s agent. It deleted his production database, ignored his instruction to freeze the code and invented data along the way, as The Register reported. Replit’s chief executive called it “unacceptable” the same week.

Replit’s fix was the correct one, and it is worth noticing what it was. Apps now get two databases, and the current documentation says the agent “can’t touch” the production one. That’s a separation any developer would have set up on day one. The tool learned it from an incident.

I have my own version of this lesson. A model I was testing followed an instruction hidden inside a text file, eight runs out of eight. An agent with write access to your live data will one day do something you didn’t ask for. The question is whether the data survives it. The same thinking decides whether an AI chatbot is safe on your website: what matters is what it is connected to.

Where this is actually heading

I’m not going to predict adoption figures. Here’s what has been said on the record.

The NCSC blog expects that over the next five years it “will become increasingly common to see AI-written code in production systems that a human has never reviewed or even looked at”. On the day it went up, the NCSC’s chief executive, Richard Horne, used his RSAC keynote to call for safeguards around vibe coding, per the NCSC’s own news release. Chismon also points out that organisations will still need somewhere to run all these new applications.

For a small business, my reading is simple. Writing the first version gets cheaper every quarter. Hosting it, keeping its data apart, backing it up and knowing who owns the account do not, and those were always most of the work.

What I would do in your position

Build the prototype yourself. I mean that. You will learn more about what you actually want from an afternoon in Lovable than from any requirements document, and it costs you a subscription rather than a project fee.

Stop before real customer data goes in. That’s the line. A demo with made-up names is a sketch. The moment it holds somebody else’s details, or two different customers log into it, it is a system with legal weight behind it.

Then bring the prototype to a call. It is the best brief anybody can hand me, far better than a description. I will read the code and tell you honestly what it is. Sometimes the answer is that the screens are fine and the data layer needs rebuilding. Sometimes it is fine and only needs deploying properly, to a server in your name, with backups that have actually been restored.

The build itself is a fixed price per project, quoted after a free scoping call, never a day rate. A small internal tool is usually two to four weeks; larger builds go in stages you sign off one at a time. You get the source code and the credentials. Nothing stays in my account, or an AI vendor’s.

When I would tell you to keep the AI version

If you are the only person using it and it holds nothing sensitive, keep it. A single-user tool that saves you an hour a week doesn’t need me.

Same if off-the-shelf software already does the job. The NCSC blog’s startup rebuilt a SaaS product to escape a price rise. That makes sense when you have an engineer to maintain the result. Most businesses I talk to don’t, and a £30 subscription that somebody else patches is often the better trade.

And I am one person, taking a few projects at a time. If you need a team by next month, I’ll tell you on the first call.

If the prototype has reached the point where other people need to log in, the software builds page has what’s included and how it’s priced.