Vibe Coding for Business: What Nobody Tells You About Managing What Gets Built

Vibe coding — building software by describing what you want to an AI and letting it write the code — has genuinely changed what businesses can build without a development team. Tools like Claude, Cursor and GitHub Copilot have collapsed the cost and time of creating a working internal app from months and tens of thousands of pounds to an afternoon and almost nothing.

That is a real shift, not hype. A team that previously had to live with an inadequate spreadsheet, a clunky off-the-shelf tool that almost fits, or a months-long wait for a developer now has a different option. They can describe the thing they need, iterate with an AI until it works, and have something usable by the end of the week.

The problem is not the building. The problem is what happens next.

What vibe coding changed — and what it didn't

Vibe coding collapsed the cost of getting an app to a state where it works. It did not collapse the cost of running one safely. Those are different problems, and most businesses discover the gap at the worst possible moment: when the app breaks, when someone leaves, or when a client or auditor asks a question about data handling that nobody can answer.

Running software in a business context has always required things that have nothing to do with whether the code executes:

• Someone needs to own it — know what it does, where it runs, what it connects to.
• It needs to be secured — access controls, secrets management, data handling policies.
• It needs to be monitored — so you know when it stops working before your users do.
• It needs to be backed up — so a platform failure or accidental deletion doesn't mean data gone for good.
• It needs to be integrated properly — not as a brittle one-off connection, but in a way that holds as both systems change.

None of this is new. What is new is that the number of apps requiring all of it has increased sharply — because building them is now accessible to people who have never had to think about what comes after.

What ungoverned AI-built apps actually look like

Here is the pattern that emerges when businesses start vibe coding without a framework for what happens after:

The app lives in one person's account.It was built by the ops manager, or an enthusiastic junior, or the MD on a Saturday afternoon. It works. Everyone starts using it. Then that person leaves, changes role, or goes on holiday — and nobody knows the credentials, where it's hosted, or how to change anything about it.

Nobody knows what it's connected to.The app reads from a spreadsheet, pushes to HubSpot, and emails someone a daily summary. Those connections were set up with an API key someone copied from a browser tab. That key has never been rotated. Nobody knows whose account it's in. Nobody knows what would happen if it was compromised.

There is no monitoring. The app works until it stops. When it stops, nobody knows for how long it has been broken — because there is no alert, no health check, and no log. The first sign of a problem is a confused user, not a notification.

Security was never part of the build. The code was written by an AI that was asked to make something work, not to make it secure. Default configurations, over-permissioned access, and client data handled in ways that would concern your GDPR obligations — not from negligence, but because nobody asked the right questions during the build.

It is growing. One app becomes three, then six. Each one was built quickly, each one does something useful, and the complexity compounds with every addition. The estate is not documented. The integrations interact in ways nobody intended. A change to one thing breaks something else.

The same app, governed properly

The answer is not to stop building with AI. The productivity gain is real and the competitive advantage for businesses that use it well is significant. The answer is to build with a framework that means everything built is safe to rely on.

That means deciding, before the first app is deployed, where it will live, how it will be monitored, who owns it, how it connects to other systems, and what security standard it has to meet. It means having an integration layer that connects every app to your existing tools in one controlled place — not a web of individual API keys and one-off connections. And it means having someone responsible for deploying, monitoring, maintaining and supporting every app once it is running.

The cost of getting an app working has collapsed. The cost of running software safely in a business has not. The gap between those two things is where technical debt accumulates — quietly, until it is not quiet.

We built LBT Managed App Framework to close that gap — not by slowing down how fast your team can build, but by providing the governance, deployment and management that means what gets built is an asset rather than a liability. The framework came out of how we manage our own AI-built apps internally: the same architecture guardrails, the same integration layer, the same deployment and monitoring discipline, now available to the businesses we work with.

If your team has started building with AI — or is about to — that is the conversation worth having before the estate gets complicated.