AI can build your app. It can't make it safe to sell. That's the gap almost every founder who builds a vibe-coded or no-code product walks into: the demo works, users are signing up, and then the first serious commercial customer asks a few procurement questions and everything stops. The prototype was the easy 80%. What makes a product sellable to real businesses, especially regulated UK ones, is the 20% the AI tools don't build for you.
To be fair to these tools, we use them too. They let a non-technical expert turn an idea into a working product in days, for a fraction of a traditional build. Validating that people want the thing is the hardest part of starting a software business, and that's now almost free. The problem is never the demo. It's what happens when you try to sell it.
The same pattern comes up again and again. Someone with deep industry knowledge builds a tool that solves a real, expensive problem. It demos beautifully. They take it to a big customer, who loves it, then hands over a security questionnaire, asks for a penetration test report, or wants to know where the data is hosted. The founder has no answers, because the tool they built with never asked those questions.
We recently assessed a UK compliance-SaaS app built single-handedly by an industry veteran on an AI app builder. It generated safety paperwork for construction and utility contractors, and the domain logic was genuinely excellent, better than some funded competitors. Then he tried to sell to Tier 1 contractors and procurement stopped him cold: no data isolation between customers, no certifications, no controls on the AI, running on a consumer hosting tier. Brilliant domain expertise trapped in unsellable infrastructure.
That gap has a name: the last mile. And it's common. Gartner found 43% of citizen-developer projects launched in the previous three years were later scaled back, paused, or shut down, mostly through governance and security failures rather than a bad idea. The demo creates false confidence and hides the fact that the expensive, unglamorous part of a commercial product is still ahead of you.

Start with the most dangerous thing a vibe-coded product can do, because founders almost never see it coming. If your app uses an AI model to generate content a person relies on, and that content is safety-critical or legally significant, you've built a liability engine with no brakes.
That compliance tool used an LLM to auto-generate method statements: the documents telling a worker how to do a dangerous job safely. But language models don't know things. They predict plausible text, and they're structurally unreliable on facts. A 2025 Stanford RegLab study tested the AI research tools sold to lawyers by Westlaw and LexisNexis, built specifically to be accurate, and found Westlaw's hallucinated on more than 34% of queries and LexisNexis's on more than 17%. Earlier work put general-purpose models at 69% to 88% wrong on specific legal questions. This is how the technology behaves.
Apply that to a method statement for a high-voltage job. If the model invents a clearance distance or drops a control, the document looks perfect: formatted, confident, and wrong. And under UK law, "the AI wrote it" is not a defence. The duty holder carries the legal responsibility for a defective safety document, whatever produced it. It's already in the courts: researcher Damien Charlotin's database catalogues more than 1,000 proceedings involving AI-fabricated citations and quotes, with sanctions running into five and six figures. The lawyer gets sanctioned, not the chatbot.

A commercial product doesn't make raw calls to a model and ship the result. It wraps the AI in controls, and none come out of a no-code builder by default.
Human-in-the-loop for anything consequential. A safety document can't be issued automatically. The software forces a named, authenticated person to review and approve it before it carries legal weight, with that approval logged. The ICO is explicit that "meaningful human involvement" means a reviewer able to actually disagree with the model, not rubber-stamp it.
Grounding and refusal. Tether the model to verified source data (official guidance, your own vetted templates) with retrieval, and make it decline when confidence is low rather than invent an answer.
Prompt-injection defence. Prompt injection is the number-one risk on the OWASP Top 10 for LLM Applications, two editions running, and can't be patched away. If you feed user text to a model, an attacker can try to hijack it into leaking another customer's data. You defend with input validation, output filtering, least-privilege tooling, and human approval for anything sensitive.
Audit trails and disclosure. Log what the AI generated, on what inputs, and who approved it, and tell users when content is AI-generated. Both are becoming legal requirements under the EU AI Act.
There's a regulatory clock, too. If you sell into the EU, the EU AI Act is in force, with transparency duties landing in December 2026 and high-risk obligations in December 2027. A safety-documentation tool could plausibly land in that high-risk bracket, which brings mandatory human oversight and conformity assessment, with fines up to 35 million euros or 7% of global turnover. The UK has no equivalent Act, but the same obligations reach you through UK GDPR and your sector regulator. Guardrails aren't polish. They're the product's licence to operate.
Set the AI output aside, and the code the AI wrote is a separate risk. Veracode's 2025 GenAI Code Security Report tested over 100 models and found that in 45% of cases the AI introduced a detectable OWASP Top 10 vulnerability into the code. Newer, bigger models did not do better. Worse, a 2025 USENIX Security study found nearly 20% of the packages AI tools recommend don't exist; attackers register those hallucinated names with malware inside ("slopsquatting"), so an AI-suggested import can pull malware into your app. Security firm Escape.tech scanned thousands of live vibe-coded apps and found 58% had a critical vulnerability, with hundreds of exposed secrets, all live and reachable within hours.
The clearest example has a CVE number. In May 2025, researchers disclosed CVE-2025-48757: a popular AI app builder was generating databases with row-level security switched off by default. The locks were missing. More than 170 live apps were exposing their databases to anyone who asked, across 303 endpoints. Every one looked finished. None was safe. If you built with an AI tool and never had the output security-reviewed, you can't assume you're not in that group.

Selling to a UK enterprise, a utility, an NHS trust, or a government supplier means a procurement gauntlet, and it's now largely pass or fail. Practitioner surveys put the share of UK enterprise buyers who treat security certifications as a hard gate at around 83%, higher at the largest firms. If you can't produce the paperwork, the deal just ends. In rough order of how early it bites:
A vendor security questionnaire, from 150 to well over a thousand questions on encryption, access controls, backups, and incident response. No documented answers, no deal.
A CREST-accredited penetration test dated within twelve months. Since February 2025 it's required for government suppliers, and scanner output doesn't count.
Cyber Essentials, often Cyber Essentials Plus, effectively mandatory for public-sector, NHS, and MOD supply chains. From April 2026, MFA is mandatory across all internet-facing accounts, with automatic failure if it's missing. A founder's personal cloud login with no MFA fails on day one.
ISO 27001 or SOC 2 Type II as deal values climb. Expect ISO 27001 to cost a small firm £10,000 to £50,000 in year one and take three to twelve months.
UK data residency. A prototype a no-code platform silently deployed to US servers is an instant rejection for a utility or government client.
None of this bolts on the week before a pitch. Certifications audit the foundations, and a prototype doesn't have any, which is the real reason a rebuild is often unavoidable.
A real product also has to obey the law of its sector, and AI builders never warn you. Under UK GDPR and the Data (Use and Access) Act 2025 (in force February 2026), your app must support erasure and data portability, notify a breach within 72 hours, and hold a processing agreement with every sub-processor. A "flat database, one login" prototype usually can't cleanly delete one customer's data, and rarely has the logging to detect a breach, let alone report it in three days. Then there's the sector layer: our example lived under CDM 2015, where risk assessment is a legal duty enforced by the HSE, which secured a 96% conviction rate and £33 million in fines in 2024/25. When your software auto-generates a document that satisfies a legal duty, it inherits real legal exposure, and every regulated sector has its own version. Selling into the EU adds the European Accessibility Act, enforceable since June 2025, which requires WCAG 2.2 AA.
So what does closing the gap involve? At the centre is a concept most founders meet for the first time: multi-tenancy. A vibe-coded app usually stores everyone's data in one pile, kept apart only by the app's own code. One bug, and Customer A sees Customer B's records. That's the CVE failure above, and an instant rejection. Real products enforce separation at the database level, and there are three common models, trading cost against isolation:
Shared database with row-level security. Everyone shares tables, but the database enforces who sees each row. Best for most B2B products: low cost, strong isolation when configured correctly.
Separate schema per customer. A shared server, each customer in their own locked compartment. A balance of separation and cost.
Separate database per customer. A physically separate database each. Best for banks, defence, and the highest-compliance clients.
Around that sits the rest of the stack: UK-region hosting, an encrypted managed database, MFA and single sign-on, a web application firewall, secrets kept out of the client, monitoring, and audit logging. None of it is exotic. It's a known, repeatable programme, usually months not weeks, and the good news is what carries over.
This is the reframe that matters, and it's genuine. The hard part of a software business isn't the infrastructure; cloud architecture, multi-tenancy, certifications, and guardrails are solved problems with known playbooks. The hard part is knowing what to build and proving people want it, and you've done that. Your demo proved the idea and the market. When we take a vibe-coded product to production, your domain logic, UI, and business rules carry forward; what gets rebuilt is underneath. Retrofitting a proper data model later costs several times more than building it right, and true data isolation can't be bolted on afterwards, so sequencing matters. You're not throwing work away. You're protecting an asset by putting it on foundations that can hold an enterprise contract.
That's the gap our Vibe Code to Production service closes: you built the idea, the domain knowledge, and the working demo; we build the secure multi-tenant architecture, the compliance foundations, the AI guardrails, and the certifications path through enterprise procurement. If you're not sure how much of your prototype carries forward, the App Gameplan is a fixed-price, four-week assessment that tells you exactly that, or get in touch to talk through where your app stands today.
Probably not without a review, and that's no criticism of you. Testing found 45% of AI-generated code contains a known vulnerability (Veracode, 2025) and 58% of live vibe-coded apps had a critical flaw (Escape.tech). The common issues, exposed secrets, missing data isolation, and no audit logging, are exactly what enterprise buyers test for. A short security assessment tells you where you stand before a customer's questionnaire does.
Usually not entirely. Your domain logic, UI, business rules, and validated product-market fit carry forward. What gets rebuilt is the layer underneath: backend, data model, authentication, and hosting, because that's what certifications audit and what multi-tenancy depends on. A scoping assessment identifies what's salvageable before you spend on development.
For public-sector, NHS, or MOD supply chains, Cyber Essentials (and often Cyber Essentials Plus) is effectively mandatory. As deal values rise, larger enterprises ask for ISO 27001 (UK and EU) or SOC 2 Type II (US-facing). You'll also need a recent CREST-accredited penetration test and a data-processing agreement. These audit your architecture, so they can't be added at the last minute.
If that content is safety-critical or legally binding, the risk is significant. Models hallucinate on a meaningful share of factual queries, and under UK law the liability for a wrong output falls on you, not the AI vendor. A commercial AI feature needs guardrails: human review and sign-off before anything consequential is issued, grounding in verified data, prompt-injection defence, audit logging, and disclosure that content is AI-generated. These are increasingly legal requirements under the EU AI Act.