The vibe-coding SDLC

Most companies handle vibe coding in one of two ways, and both are a mistake.

Ban it. Lock down the AI tools, forbid the practice, wait for the risk to pass. What actually happens: your best people build anyway — on personal ChatGPT accounts, on their own laptops, with company data pasted into a chat box you can’t see. You didn’t stop shadow IT. You made it invisible.

Wave it through. Let everyone build whatever they want, however they want. It works beautifully right until someone wires a quick tool to your customer database and stands it up on the open internet with no login on it. That’s not a productivity story any more. It’s an incident, and it’s a matter of when, not if.

There’s a third path, and it isn’t complicated. You give vibe coding a lifecycle — not a bureaucracy, a set of rails that make the safe way the easy way. Here’s what that looks like, and how much of it a platform like Croft can carry for you.

First: why let your team vibe-code at all?

Because the person who does the work understands the work. The oldest critique of engineering teams is that they sit too far from the coalface to feel the friction the way the people living it do. Your operations lead knows exactly where the process breaks. Your finance manager knows exactly what the spreadsheet can’t do. Until now, that knowledge had to survive a game of telephone through a backlog to become software. It rarely did.

Three more reasons it’s worth doing on purpose:

• They’ll build anyway. The only real choice is whether it happens on sanctioned, governed rails or on personal accounts you can’t see. Governed beats invisible every time.
• Most of it is cheap wins, a little of it is outsized. Plenty of these apps will be used by three people and then retired. That’s fine — they cost an afternoon. The handful that catch on across a department pay for the whole programme.
• One good tool becomes many. A build that solves one person’s problem tends to solve the same problem for everyone sitting near them — if you make it easy to share.

What you’re actually optimising for

Enable vibe coding deliberately and you’re steering toward five things:

• Turning the doers into the builders. The subject-matter expert, not a ticket, becomes the person who ships the fix.
• Making it multiplayer. An app that runs on one laptop is a party trick. An app the whole team logs into and improves is leverage.
• Letting IT sleep at night. IT isn’t anti-vibe-coding. They’re anti-being-the-one-whose-name-is-on-the-breach. Give them guardrails and the resistance disappears.
• Governing data access instead of gatekeeping it. Before AI, a team might field five data requests a week. Now it’s fifty a day. You cannot approve that queue by hand — access has to be a governed switch, not a favour.
• Consistency by default. If every app is shaped roughly the same way — same sign-in, same hosting, same guarantees — then anyone can pick one up, and nothing is a bespoke liability.

A lifecycle for vibe coding

Put those together and you get a simple, repeatable path from idea to running app. Five stages:

1. Describe. The person with the problem briefs their AI — the idea, who’ll use it, what data it needs, how it should behave. Plain words in, a clear shape out. No PRD template required; the point is that the intent is written down before anything is built.

2. Land on the paved road. This is the stage most companies get wrong, because they try to build the road themselves — repos, environments, identities, infrastructure-as-code — before anyone can ship a thing. On Croft the road already exists. Before a single line of the app’s code runs, it’s born on your own private server, behind one company sign-on, with a database and HTTPS already in place. The guardrails come first, automatically — not as a review someone remembers to do later.

3. Build inside the rails. The builder prompts their coding agent — Claude, ChatGPT, Grok, Copilot, any tool that speaks the open standard — and the app deploys onto their croft, already behind the login. Everything an engineer would normally have to carry — hosting, auth, TLS, a database — is carried by the platform instead. They add the behaviour; the rails hold the rest.

4. Govern the data and the access. Two switches, both owned by an admin, neither living in the app’s code. Connectors hold your API keys centrally, so a build reaches Stripe or your CRM without a key ever being pasted into a prompt — and a sensitive source can require an admin’s sign-off, with an audit trail, before any app may touch it. Access works the same way: you grant it app by app, and when someone leaves, you remove them once and they’re out of everything.

5. Run and change safely. Every deploy is versioned and reversible — a bad change from the AI is a one-click rollback, not a crisis. Every app is backed up continuously to separate storage, and the restores are tested. When something breaks, the assistant reads the app’s own logs, fixes the code it wrote, and redeploys. You don’t sit a human in front of every routine edit, because the risky surfaces — who can get in, what data they can reach, whether a change can be undone — are guaranteed by the platform, not by whoever wrote the prompt. What still deserves a human is the consequential tail: a new sensitive data connection, a wider share. Those, and only those, ask for a sign-off.

You don’t need to build the rails

The heavyweight version of this — a platform-engineering team standing up repos, triage pipelines and infrastructure-as-code — is real, and it’s what a Fortune 500 needs. Most businesses don’t have that team, and shouldn’t have to hire one to let their people build a stocktake app safely.

That’s the whole idea behind Croft. The lifecycle above isn’t a project you run; it’s the shape of the platform. The blast radius of any given build is capped before it’s built — private by default, behind your sign-on, reversible, backed up, its data access gated by an admin. So the process gets lighter, not heavier: you get enterprise-grade security with none of the enterprise, and your team gets to build at the speed the AI now makes possible.

Enable vibe coding, but do it on rails. That’s the difference between accelerating your business and waiting for the bad day.

See how Croft handles security →

More from the blog