A Vibe-to-Production Checklist for Solo Builders and Small Teams

This series started with a distinction worth restating plainly: vibe coding — describing what you want, accepting the generated code, moving fast — is a legitimate, valuable technique for the code you intend to prototype or throw away. It becomes a liability only when it's applied, unmodified, to code that's about to matter: touching real users, real data, real money. Every piece since has dug into a specific way that liability shows up — leaked credentials, rising technical debt, ballooning maintenance costs, recurring vulnerability classes, and what an actual review process looks like when you build one on purpose instead of hoping for the best.

This piece closes the series with the thing all of that should add up to: a checklist you can actually use, not another abstract argument for being more careful. Pin this somewhere your team will actually see it.

Before you generate: decide the tier

1. Classify the code's blast radius before you write the prompt, not after the code exists. Is this reversible within hours if wrong, or expensive and slow to detect and fix? The reversibility question should drive everything downstream — deciding it after the code is already written is exactly when convenient rationalization creeps in.

2. If it's Tier 3 — customer-facing, authentication, payments, or real user data — commit to the full checklist below before you start, not as an afterthought once the deadline is close.

While you generate: catch what's cheap to catch early

3. Glance at every generated diff before committing it, checking specifically for the recurring patterns — unescaped input reaching an output context, permissive defaults where restrictive ones should be the default, authorization checks that only verify authentication. This costs a minute per diff and catches a large share of what a much more expensive later review would otherwise have to find.

4. Run automated secret-scanning as a pre-commit hook, not a CI step that fires after the code is already public. The 3.2% credential-leak rate in AI-assisted commits is exactly the kind of mechanical failure automation catches reliably without depending on anyone remembering to look.

5. Check for duplication against the existing codebase before accepting a generated solution wholesale. This is the single highest-leverage moment to prevent the technical debt that compounds into a real maintenance bill later — cheap now, expensive once three other features depend on the duplicate existing.

Before it ships: the Tier 3 gate

6. Run the five-question checklist from the review protocol on anything touching authentication, payments, or user data: unescaped input reaching output contexts, hardcoded credentials, authorization versus authentication, permissive versus restrictive defaults, unnecessary duplication.

7. Name a reviewer, every time, even on a two-person team. A checklist nobody's explicitly responsible for running is a checklist that quietly stops running the first week things get busy.

8. For genuinely high-stakes surfaces — payment handling, anything with broad data access — get a second set of eyes beyond whoever wrote the prompt. Not because the first reviewer isn't competent, but because the review-as-a-skill piece is right that continuous review degrades gracefully, but a single point of failure on your highest-stakes code doesn't.

As you scale: keep the system honest

9. Track maintenance time as an actual metric, even a rough one. If routine changes are quietly taking three times as long as they used to, that's the 300%-in-18-months pattern showing up in your own codebase, and it's far cheaper to notice early than to discover it eighteen months in.

10. Protect real calendar time for debt cleanup, not as a response to crisis but as a standing budget — a fixed percentage of engineering time spent finding and fixing the duplication and drift before it becomes load-bearing.

11. Re-classify code's tier as its stakes change, not just once at creation. A prototype that graduates into a real product feature needs its review level to graduate with it — the code doesn't announce that transition itself; someone has to notice and act on it.

12. Build pattern recognition as a running team habit, not a one-time training. A few minutes reviewing real recent pull requests together, regularly, does more for catching the recurring vulnerability classes than an annual security module anyone will read once and forget.

How to actually adopt this without a rewrite of how your team works

None of this requires a new tool stack, a security hire, or a pause on shipping to "get process in order" first — which is good, because a small team that stops to build process before it builds product usually doesn't get a second chance to build either. The realistic adoption path is incremental:

Week one: add the tier classification question to however you already plan work — a single line in the ticket or the prompt itself: "is this reversible within hours if wrong?" That's the whole change. It costs nothing and it's the highest-leverage item on this list, because everything else here only applies once something's been correctly classified as needing it.

Week two: turn on pre-commit secret scanning. This is a few minutes of setup with any of the common tools and, once running, requires zero ongoing attention — it just quietly does its job in the background of every commit from then on.

Week three: put the five-question Tier 3 checklist into your pull request template as literal checkboxes. Not a wiki page. Not a Notion doc nobody opens. In the template itself, where it's impossible to open a PR without seeing it.

Ongoing: name a rotating reviewer, protect a small recurring block of calendar time for debt cleanup, and revisit code classifications when a feature's stakes change. These are habits more than one-time setup steps, and they're the ones that fade first if nobody owns them — which is exactly why naming an owner, even informally, matters more than writing the policy down.

Notice that none of these four steps individually takes more than an afternoon. The compounding value comes from doing all of them, consistently, over months — which is a much lower bar than it sounds, because each one, once set up, runs almost entirely on its own.

What this checklist is actually optimizing for

Notice what's absent from this list: nowhere does it say "review every line" or "slow down." The entire point of everything in this series is that the fix for AI-coding risk isn't less speed — it's placing a small number of cheap, well-targeted checks at the specific points where the recurring failures actually happen, so the speed you gained from AI-assisted development doesn't get erased by cleanup costs later. A team running this checklist moves just as fast on the 80% of code that's genuinely low-stakes, and spends its limited review attention precisely on the 20% where being wrong is expensive.

That's a very different posture from either extreme this series opened by rejecting — reviewing everything, which nobody sustains under real deadlines, or reviewing nothing, which is how a team ends up inside the 65% of production apps carrying security issues that started this whole conversation.

The research behind this series is consistent about one thing across every number it produced: the failures aren't evidence that AI-generated code is fundamentally unsafe. They're evidence of what happens when a technique built for exploration gets applied, unexamined, to work that was never exploratory to begin with. The fix was never "trust the model less." It was "decide, deliberately, which code deserves scrutiny, and then actually give it that scrutiny" — which is advice that predates AI coding tools by decades and will outlast whatever comes after them too.

Vibe coding got you to the prototype fast. This checklist is what gets the parts of it that matter safely into production — and lets you keep building the next thing at the same speed you always could.

---

Part of the "From Vibe Coding to Production" series on aiskill.market.