In this post
An auditor analyzed 47 failed startups’ codebases and found the same shape every time. 91% had zero automated tests; 68% had security vulnerabilities a basic pen test would have caught. The stats weren’t even the worst part. Every single codebase followed the same decay curve.
If you’re under six months in and shipping fast, this is the shape worth recognizing before you pass the next mile marker.
The 25-month autopsy #
The auditor (Meir Avimelec Davidov of Gliltech Software) published his findings in a Hacker News thread. He’d rebuilt systems after these failures. Here’s the timeline he found:
In the first six months, everything works. Your MVP shipped on time, the demo impressed your investors, and users started signing up. The code looks clean because your team is only touching what matters - bug reports are rare, your dev shop looks solid. You’re thinking about Series A.
Between months seven and twelve, small bugs appear. A dropdown that doesn’t quite work, a confirmation email that’s occasionally late. Your dev shop says “we’ll circle back when we have a sprint.” You believe them because you also have features to ship. The velocity slows a little, but not visibly. You add another developer.
Months thirteen through eighteen is where it gets ugly. Adding a simple button causes a crash three pages deep. Your team doesn’t understand why. The codebase has no tests, so they can’t predict what breaks. Every new feature requires hours of manual regression testing. Estimates go from “3 days” to “we’re not sure.” You start hearing about “technical debt.” A customer loses data. Not permanently - you recover the backup - but you discover there’s no error handling in the payment flow. No one knows when that code was written or why.
By months nineteen through twenty-five, you’re hiring to maintain, not to build. You add two more developers, but velocity doesn’t increase - the new hires spend their first month learning the “why” behind undocumented decisions. A senior engineer quits because “the code’s a mess.” You’re shipping the same number of features with four developers as you were with two. Your burn rate hasn’t changed. Your feature delivery has collapsed.
Month twenty-five: pay $200K-$400K to rewrite from scratch (and hope the new team doesn’t repeat the same shape), or shut down.
The 47 startups in the audit covered fintech, edtech, SaaS, and marketplaces. Different industries. Same curve.
Three stats that predict your timeline #
You don’t have a year to wait for your codebase to tell you it’s broken. The auditor’s data gives you advance warning with three measurements.
Test coverage tells the story first. The auditor found 91% of failed startups had literally zero automated tests. Coverage was zero. Their code was evaluated by humans clicking buttons, then deployed to production. Ask your dev shop right now: “What’s your test coverage?” If they say “we don’t have a number,” that’s 0%. If they say “we’re planning to add tests,” you’re six months from month seven on the timeline. Healthy coverage sits at 70%+. Under 30% and you’re already in months 7-12.
Security was the second pattern. 68% of the failed startups had exploitable security holes that a basic penetration test would catch. Most were laughably simple: an authenticated user could access another user’s data by changing a number in the URL. The developers shipped features without asking “what if someone does this wrong?” If you request a security audit and the report comes back with 10+ critical issues, you’re in the danger zone.
The third stat surprised us most. 89% had no database optimization at all - think of it like a library where every book search requires reading every spine instead of checking the catalog. One startup was using only 13% of their server’s power while paying full price because the database couldn’t find data efficiently. Their app felt slow to users. Their ops person couldn’t explain why. They were months away from either a massive hosting bill increase or a painful realization that the database itself was the bottleneck.
If any of these describe your codebase, you’re past month six. The small problems are stacking up faster than you think.
How vibe coding collapses the timeline #
The Inc.com autopsy happened before the AI code explosion. Those 47 startups hired human developers who cut corners. In 2026, the corners are cut even faster.
Vibe coding - shipping AI-generated code without tests or review - doesn’t follow the 25-month timeline. It compresses it.
A vibe-coded MVP skips months 1-6 entirely. The code looks clean on day one - syntactically correct, compiles fine, passes a manual demo. But it skips the understanding phase. Your developer’s AI tool never learned your problem domain - it pattern-matched against billions of lines of training data. The result feels like a solution and reads like competent code, but nobody wrote tests or handled errors, and there’s no documentation explaining why anything works the way it does.
Month one of a vibe-coded app is actually month seven of a traditionally-built one. A user triggers an edge case and the code crashes, or worse, silently corrupts data because nobody wrote the safeguards that prevent half-finished operations from saving. The dev shop says “oh, we’ll add tests now.” Now. After hundreds of lines of code are already written. Now that rewriting is more expensive than writing it right the first time.
A vibe-coded app compresses 25 months into roughly seven. The “new features break old ones” phase hits by month four; the “rewrite or die” decision by month seven.
Veracode’s 2025 GenAI Code Security Report tested over 100 LLMs across Java, Python, C#, and JavaScript. 45% of code samples failed security tests. For Java, the failure rate hit 72%. These weren’t edge cases; they were the ten most common security flaws that hackers exploit first. Many vibe coding shops call this production-ready.
Five signals you’re on the timeline #
You don’t need to wait 25 months to know. These five things appear in order, every time. We’ve documented the full checklist if you want a deeper assessment.
It starts with the phrase “we’ll fix it later” showing up in standups. Your dev shop misses a deadline - not by much, maybe a week - and they say they’ll catch up next sprint. You believe them because the MVP shipped on time. This is month six behavior. Hear it more than once in a month, and you’ve entered the acceleration phase.
Then small changes start taking unexpectedly long. A button color change that should take an hour now takes three. The developer who built it has left, or they don’t remember why they wrote it that way, and the code has no comments. This is month nine - technical debt you can see at the task level.
By month twelve, new features break unrelated things. You request a reporting feature. It ships. Three customer complaints arrive about a bug in the checkout flow. The new code touched a shared function used in 12 places, and nobody had written tests to catch the side effect.
Month fourteen brings the documentation question. A new hire needs to understand the authentication flow. The dev shop points them at the code. There’s no design doc, no notes on why anything was built the way it was. New hires spend their first two weeks just learning the codebase. Your velocity plateaus because onboarding becomes a full-time job.
The fifth signal is easy to miss: you hire a third or fourth developer and feature output stays flat. Month eighteen. Everyone’s time goes to bug fixes and explaining decisions to each other, and you realize the team has stopped building and started maintaining.
Two of these signals means you’re on the timeline. Four means you have at most six months before the rewrite conversation.
Where you can break the cycle #
The timeline isn’t inevitable. Teams can stop at month six and rebuild the right way. Month nine is harder but possible. Month eighteen? You’re basically rewriting.
The honest trade-off: enforcing tests and code review from day one slows your first three sprints by 20-30%. If you haven’t found product-market fit yet, that cost is real, and we won’t pretend otherwise. Here’s where intervention works:
Month 6: the go/no-go decision #
After the MVP ships, hire an independent engineer to spend 40 hours reading your code. They write a one-page report: test coverage %, security holes (count and severity), architectural debt (estimate to fix), and a clear recommendation. Either keep building features or stop and fix fundamentals. This costs $8K-$15K. You catch the timeline before it accelerates.
Month 12: add a senior engineer or fractional CTO #
At this point, your dev shop knows how to build features but not how to build maintainable systems. A senior engineer or fractional CTO working 10-15 hours/week establishes the practices that prevent acceleration: tests required before review, at least two people on every code review, an indexing strategy for database changes, standardized error handling. The cost is $5K-$15K/month. Here’s what that enforcement looks like in practice.
Month 18: the last window before rewrite #
If you’re here, your options are limited. A rewrite buys you time, but the rewrite needs discipline or you repeat the pattern. This is where the next team has to install the practices that prevent the 25-month timeline from repeating, with our exit guide covering the contract side. Need engineers for this? See how we work.
When to rewrite vs. rescue #
Both options take months. The deciding question isn’t your codebase. It’s whether the next team can commit to writing tests. If they’ll “get back to it later,” rewrite with new people. If they’ll start tomorrow, rescue.
The codebase factors that push toward rescue: architecture is sound, the code is under twelve months old, and a senior engineer can read the most-edited file without needing a glossary. The factors that push toward rewrite: 18+ months untested, no documentation, and the team that built it has scattered.
The same mistake, 47 times #
The 47 startups in the Inc.com audit didn’t fail because they hired bad developers. They failed because they kept deferring the infrastructure work. “We’ll add tests when we’re bigger” was the most common version of the line; what happened next depended on who was doing the deferring and for how long. Reasonable in isolation, the deferrals stacked into a timeline.
The vibe coding shops are accelerating this timeline because AI makes it easy to believe you can defer forever - you’ll iterate so fast that the debt will never catch up, and eventually you’ll hire experienced people who’ll clean it all up. That’s the story every founder tells themselves until month seven arrives.
If you’re still in months one through six, you have a choice. Pick three founders you respect who shipped a product that lasted past year three and ask them when they started enforcing tests. The answer will be earlier than you wanted to hear.
Run the three checks from the audit: test coverage, a security scan, and a database health check. The numbers will tell you which month you’re in.
Sources:
