Someone on your team built an app last Tuesday. They described what they wanted to an AI, it wrote the code, and by the afternoon there was a working tool: a job tracker, a quote calculator, a form that drops customer requests into a sheet. It looks good. It works. People have started using it. That's the moment worth pausing on, because a thing that works on Tuesday and a thing the business can rely on in March are two different promises.
What vibe coding actually changed
"Vibe coding" is the name that stuck for building software by describing it rather than writing it. It's real, and we're not going to pretend otherwise: we build software for a living, and AI writes a large share of the code we ship. The tools are very good at producing something that runs. What they don't produce by default is everything around the code that makes a tool safe to depend on — who can log in, where the data goes, what happens at 2am when it stops, and who can fix it.
Those aren't coding questions, which is why an afternoon build skips them. They're business questions. And they're where the vibe coding security risks actually live: rarely in a clever attack, almost always in a door nobody knew was open.
Four questions before your team relies on it
Who can get in? Plenty of quick builds have no login at all, or a single shared password, or a link that works for anyone who has it. That's fine for a demo. It stops being fine the day the tool holds a customer's phone number. Ask: does every person have their own account, can you remove someone who leaves, and is anything reachable by someone who simply guesses the address?
Where does the data live, and who holds the keys? Quick builds often sit on a personal account — the builder's own login, the builder's own card. If they leave, the tool leaves with them. The other common slip is keys pasted straight into the code: the password to your email service or payment account, sitting in a file that may be visible to anyone who opens the page's source. We wrote about the ownership side of this in who actually owns your business data; a homemade app can create the same trap from the inside.
What happens when it breaks? Everything breaks eventually. A form stops submitting, an import fails, a scheduled job quietly stops running. The dangerous failure isn't the loud one; it's the silent one, where the team keeps entering data into something that stopped saving it three weeks ago. Ask: if this stopped working tonight, how would anyone find out?
Who fixes it? If the person who built it is away, can anyone else change it? Is the code somewhere the business controls, with a history of what changed and when? "Ask the AI again" works until the fix touches something the first version got subtly wrong and nobody remembers why it was built that way.
A prototype answers "can this work?" A system answers "what happens when it doesn't?" Most afternoon builds only ever asked the first question.
What we do differently when we build one
The code is rarely the difference. What we add is the dull scaffolding around it. Every person gets their own login, and access is removed in one place. Secrets live outside the code. Data sits in an account the business owns, not one of ours and not an employee's. Every scheduled job reports in when it runs, and a separate check raises an alarm when a report doesn't arrive — that's how our own publishing runs, so a missed run gets flagged instead of discovered by accident. None of it is exotic. It's just the part an afternoon doesn't leave time for.
The same thinking applies when the builder is an AI agent rather than a person. An agent that can write and deploy code is, in effect, an assistant with keys, and the rule is the same: decide what it can touch before you decide what it should do.
Keep it, harden it, or rebuild it
Not every vibe-coded app needs rescuing. A tool one person uses to tidy their own notes can stay exactly as it is. The line is crossed when three things are true: more than one person depends on it, it holds customer or financial data, and the work would stall if it disappeared. Once all three are true, it's a system, whether anyone planned one or not.
At that point there are honest options. Sometimes the answer is to harden what's there: add real logins, move the keys, set up a check that it's still running. Sometimes the prototype is best treated as a very good specification, and the durable version is built properly from it — which is often faster than it sounds, because the hard part, knowing exactly what the business needs, is already done. And sometimes the right answer is an off-the-shelf product after all; we walked through that decision in what we build when a business says it needs software.
It's early for all of this. The tools are improving month to month, and some of these gaps will close on their own. We'd be lying if we said we knew which ones. For now, the four questions are the cheapest insurance a business can buy.
Where to start
Make a list of every tool your team built or set up themselves in the last year, and run each one through the four questions. The ones that fail on "who can get in" come first. If you'd rather have someone map what your business actually runs on — the homemade tools, the subscriptions and the handoffs between them — and tell you which three things to fix first, that's what our THINQ Diagnostic is for.
