Vibe Coding For Business: When AI-Built Apps Work And When They Don’t

AI app builders have changed who gets to make software. Tools such as Lovable and Zite let someone with no coding background describe an app in plain English and get a working version back in minutes. For a business, that is a real shift: the backlog of small tools nobody ever had the budget to build suddenly looks achievable.

It has also created a new kind of risk. An app that works in a demo is not the same as an app that is safe to run your customers’ data through. This guide sets out where vibe coding earns its place in a business in 2027, where AI-built apps tend to break, the warning signs to watch for, and the point at which it makes sense to bring in an expert.

What Vibe Coding Means For A Business

Vibe coding means building software by prompting an AI model and working with what it produces, refining the result through conversation rather than writing or closely reviewing the code yourself. If you are new to the idea, our guide to no-code app builders covers the wider landscape.

Business-focused tools fall into two broad camps. Lovable generates a full web application, front end and back end, from a chat, and lets you keep editing the underlying code. Zite, from the makers of the form builder Fillout, is aimed squarely at business systems. Its documentation lists CRMs, client portals, inventory systems and approval processes as typical builds, with a shared workspace database and sign-in options that include Google and single sign-on.

Both make the first version of an app feel almost free. The hard part is everything that comes after the first version, and that is what the rest of this guide is about.

Where AI-Built Apps Work Well

Internal tools for a small, known group of users

Request forms, job trackers, approval flows and simple dashboards over data you already hold are the sweet spot. The users are your own staff, the data is usually lower risk, and if something goes wrong the cost is an inconvenience rather than a breach. These are also the tools that rarely justify a traditional development project, which is why so many businesses still run them on email and spreadsheets.

Prototypes and proofs of concept

An AI-built prototype is a cheap way to test an idea with real users before you commit a proper budget. It gives stakeholders something to click rather than a specification to imagine. The rule that keeps prototypes useful is simple: agree before you start that it will be reviewed or rebuilt before it goes anywhere near customers.

Client and partner portals with simple permissions

Portals where customers upload documents, check the status of a job or book a slot can work well, especially on a platform that handles sign-in for you. The condition is that the permissions are simple and that someone tests them properly. “Customers see only their own records” sounds obvious, but it is exactly the rule that AI-generated apps most often get wrong.

Replacing spreadsheets that have outgrown themselves

When a shared spreadsheet has become the operating system for a team, with colour codes, hidden tabs and one person who understands it, a small purpose-built app can bring real order. The gains come from fixing the process, though, with the tool as the means rather than the point. Map how the work actually flows, agree what each field means and who owns it, and only then ask the AI to build around it.

Where AI-Built Apps Break

Security

AI models write code that runs, not code that is secure by default. In research published by Veracode in July 2025, more than 100 large language models were tested on 80 coding tasks, and the AI-generated code introduced security vulnerabilities in 45% of cases. Cross-site scripting defences failed 86% of the time.

App builders have had their own incidents. In 2025 a researcher scanned 1,645 projects showcased by Lovable and found 170 applications whose database access rules were missing or misconfigured, exposing data such as user records and API keys. The issue was logged as CVE-2025-48757. Lovable has since added automatic and on-demand security scans, but its own security documentation is clear that the app owner remains responsible for meeting the security requirements of their use case, and that the scans cannot guarantee complete security. We cover the common failure points in more depth in vibe coding security risks and how to fix them.

Data handling and UK GDPR

Under UK GDPR, the duty to protect personal data sits with your business, not with the tool you used to build the app. The ICO’s security guidance points to Article 32, which requires appropriate technical and organisational measures for the level of risk. In practice that means knowing where the app stores data, which third parties process it, who can access it and how long it is kept.

If the app itself uses AI to process personal data, the stakes rise again. The ICO’s guidance on AI and data protection says that in the vast majority of cases this will be high-risk processing that legally requires a data protection impact assessment. Few people building an app over a weekend think to do one.

Apps nobody approved

The ease of these tools is also their governance problem. When anyone can build an app, departments start running business processes and customer data through tools IT has never seen. This is Shadow IT in a new form, and the answer that tends to work is governance and guardrails around approved AI use rather than an outright ban, which simply pushes the building out of sight. A short list of approved tools, clear rules on what data may go into them and a named owner for every app will prevent most of the problems in this section.

Scaling

AI-generated apps are optimised to work now, for the person testing them. Decisions about the data model, how records relate to each other and how the app behaves with hundreds of simultaneous users are made implicitly, often without anyone noticing. An app that is quick with ten users can slow badly at a thousand, and usage-based pricing on some platforms means running costs can climb as quickly as adoption does.

Maintenance

Every app needs fixing and changing over its life. With an AI-built app, the person who prompted it may be the only one who knows how it fits together, and they may not fully understand the code either. New prompts can quietly rewrite parts of the app that were working, and there are rarely automated tests to catch it.

The best-known warning came in July 2025, when SaaStr founder Jason Lemkin reported that Replit’s AI agent had deleted a production database despite instructions to freeze changes. Replit’s chief executive called it unacceptable and the company rolled out automatic separation of development and production databases. The lesson for any business is the same: keep backups you have tested, and never let an AI agent work directly on live data.

Compliance and audit

Regulated businesses, and anyone selling to them, need audit trails, access logs, change control and evidence of supplier due diligence. An AI-built app may run perfectly and still fail a client’s security questionnaire because nobody can show how it was tested or who changed what. The ICO describes the government’s Cyber Essentials scheme as a good starting point for basic technical controls, and it is a reasonable baseline to check any business app against.

AI-Built Apps At A Glance: Good Fit Or Not

Use case	Usually a good fit?	Main risk	What to put in place
Internal tracker or dashboard for staff	Yes	Access creeping wider as more people join	A named owner and a regular review of who can see what
Prototype to test an idea	Yes	The prototype quietly becomes the live product	Agree up front that it will be reviewed or rebuilt before launch
Client portal with simple permissions	Often, with review	One customer seeing another customer’s data	Test every role with real accounts before launch
App handling payments, health or financial data	Rarely without expert help	Data breach and regulatory exposure	Security review, DPIA and penetration test
Customer-facing product expected to scale	Only as a starting point	Performance and maintainability	Engineering review and a plan to harden or rebuild

Warning Signs Your AI-Built App Needs Help

If any of these sound familiar, the app has probably outgrown the way it was built:

• Nobody can explain how users sign in or exactly what each role is allowed to see.
• API keys or passwords have been pasted into prompts or sit in the front-end code.
• The app holds customer personal data, but there is no record of where it is stored or who processes it.
• Every new prompt fixes one thing and breaks another.
• There is no separate test environment and no backup you have actually tried restoring.
• One person built it, and the business would stall if they left.
• A client, insurer or auditor has sent a security questionnaire you cannot answer.
• Usage or credit costs are rising faster than the number of people using the app.

When To Bring In An Expert

Not every AI-built app needs a consultant. A useful rule of thumb: the closer an app gets to customers, money or personal data, the more it needs someone who can read the code and the data model, not just the interface.

Before you build: choosing the right use cases

The cheapest time to get help is before the first prompt. Deciding which processes are worth an app, which data may go into AI tools and who owns each build saves far more than any later fix. A good adviser will start with a readiness audit, talk to the teams who do the work, assess processes before tools, shortlist use cases and help you pick internal champions, and only then move on to planning, building and measuring. If you want context first, our look at why UK small businesses are using AI but not seeing results is a good place to start.

Before you launch: a security and data review

Any app that will be used by customers, or that holds personal or financial data, should be reviewed before it goes live. That means checking access rules role by role, moving secrets out of the code, confirming where data is hosted, completing a DPIA where the law requires one and, for higher-risk apps, commissioning a penetration test.

After launch: when the app starts slowing you down

If the warning signs above are piling up, the choice is usually between hardening what you have and starting again on firmer foundations. Our guide to whether to rescue or rebuild a vibe-coded MVP walks through that decision, and our list of vibe code cleanup and rescue services covers specialists who do this work.

Frequently Asked Questions

Is vibe coding safe for business use?

It can be, for the right jobs. Internal tools, prototypes and simple portals are reasonable uses. Apps that handle payments, health data or large volumes of customer data need a proper security and data review before launch, whichever tool built them.

What is the difference between Lovable and Zite?

Lovable generates full web applications from a conversation and gives you the code to keep editing. Zite, from the makers of Fillout, focuses on business systems such as CRMs, portals and approval flows, with a built-in workspace database and managed sign-in. Many businesses will find Zite a better fit for internal operations and Lovable more flexible for custom products.

Can I put customer data into an AI-built app under UK GDPR?

Yes, but the obligations are yours. You need to know where the data is stored, which processors are involved, who has access and how it is secured. If the app uses AI to process personal data, the ICO expects a data protection impact assessment in most cases.

Should we rebuild a vibe-coded app from scratch?

Not automatically. If the data model is sound and the problems are limited to security settings and tidy-up, hardening is usually cheaper. If every change breaks something else, or the app now carries core business processes, a planned rebuild is often the better investment.

Conclusion

Vibe coding is a genuinely useful business tool in 2027. Used for internal tools, prototypes and simple portals, AI app builders such as Lovable and Zite can clear years of small software backlog in weeks. Used for customer-facing products that handle sensitive data, without review, they create security, compliance and maintenance problems that cost far more than they saved.

The businesses that get the most from these tools treat them like any other system: they choose use cases deliberately, set rules on data and ownership, and bring in expert help before the stakes get high rather than after something breaks.