75% of Software Is Rewritten Code
Most founders don’t realize they’re paying for the same product three times.
They call it iteration. Agile development. Learning as they go. But when you look at the actual capital burn, something darker emerges. The authentication system gets rebuilt. The dashboard gets rewritten. The database schema gets migrated. Not because the first version was broken, but because nobody understood what they were building until after they built it wrong.
This isn’t about bad developers or indecisive founders. It’s about a structural trap that hides inside the word “progress.” Every new feature feels like forward motion. But under the surface, a shocking percentage of engineering time goes to rebuilding commodity infrastructure that already existed somewhere else.
The real MVPs don’t fail because they lack innovation. They fail because founders burn runway rebuilding login systems while competitors ship actual value.
The Invisible Rebuild
Here’s what the budget breakdown actually looks like for most early-stage products.
A founder raises $150K. Hires a dev team or contracts a shop. Six months later, they’ve spent $80K on development. They have something that works. Sort of.
Then they look closer. The user authentication they built from scratch? There were three production-ready libraries that did it better. The admin dashboard they spent five weeks perfecting? It’s not connected to the core business logic that actually generates revenue. The API they architected for “future flexibility”? It supports features they don’t need and probably never will.
Nobody planned to waste money. But without a clear split between commodity components and core product logic, engineering effort flows to the path of least resistance. And the path of least resistance is often rebuilding things that already exist because that’s what developers know how to do.
We analyzed portfolio data from angel networks across Canada. The pattern was consistent. Startups that survived past Series A had one thing in common: they spent less than 30% of initial development budget on infrastructure and more than 70% on differentiated product logic.
The ones that failed? Reversed ratio. They poured capital into infrastructure, then ran out of money before proving their unique value.
Why Founders Default to Rebuilding
The trap starts with how founders think about custom software.
There’s an assumption, usually unconscious, that “custom” means “built from scratch.” That paying for development means paying for creation. That the value comes from having developers write new code.
This is backwards.
The value comes from having developers connect your unique business logic to proven infrastructure. The login system doesn’t matter. What happens after login matters. The payment processing doesn’t matter. What users buy and why they buy it matters.
But founders don’t know which parts are commodity. They don’t know that authentication, role-based permissions, email notifications, file uploads, search, pagination, caching, background jobs, these are solved problems with battle-tested implementations.
So when a developer says “we’ll build a custom authentication system,” the founder hears “we’re building something tailored to your needs.” What’s actually happening is the developer is rebuilding something that’s been rebuilt ten thousand times because they either don’t know about existing solutions or they prefer to write code they control.
Both reasons are understandable. Neither is defensible when you’re burning limited runway.
Why Engineers Often Push for Custom
Developers aren’t trying to waste money. They’re optimizing for what they were trained to optimize for: technical control, learning opportunities, and avoiding external dependencies.
Here’s what goes through a developer’s mind when they suggest building from scratch:
“If we use a library, we’re dependent on someone else’s code. What if it has bugs? What if it doesn’t do exactly what we need? What if the maintainer abandons it? If we build it ourselves, we control everything.”
This logic makes sense in a vacuum. In reality, it’s expensive rationalization.
That authentication library they’re worried about? It’s been used by 50,000 other projects. It’s had hundreds of contributors finding and fixing edge cases. It’s been tested against security vulnerabilities by people whose full-time job is breaking authentication systems.
Your custom authentication system? It’s been tested by your one developer who’s also trying to build five other features this sprint.
Which one is more likely to fail in production?
The other driver is honest: developers like building things. It’s more interesting to architect a solution than to integrate someone else’s. There’s pride in creation. There’s learning in implementation.
But the startup isn’t paying for interesting work. It’s paying for delivered value. And delivered value comes from ruthlessly separating what’s unique from what’s commodity.
The “This Time It’s Different” Trap
Even when founders understand the commodity versus core distinction, they convince themselves their case is special.
“Yes, most authentication is standard. But our users need to log in with their university email and verify they’re currently enrolled. That’s custom, right?”
No. That’s still commodity. University email authentication is OAuth. Enrollment verification is an API call to the registrar system. Both are integration problems, not novel engineering challenges.
“But we need real-time collaboration with conflict resolution. That’s complex. We have to build it custom.”
No. Operational transformation is solved. CRDTs are solved. There are libraries for this. Your product’s unique value isn’t the conflict resolution algorithm. It’s what users are collaborating on and why they need to collaborate.
The trap is that everything feels special when it’s your product. Every requirement sounds unique when you’re close to it. But step back and most software is assembled from the same building blocks, arranged differently.
The arrangement is what matters. The blocks themselves are commodity.
How Invisible Rebuilds Quietly Kill Runway
The real damage isn’t the money spent on any single rebuild. It’s the opportunity cost that never shows up on an invoice.
A founder has a $120K development budget. Enough for roughly 800 hours of senior engineering time at $150/hour. Or 1,600 hours at $75/hour if they go offshore.
Now, how should those hours be spent?
Option A: Build everything from scratch
- 200 hours on authentication
- 150 hours on admin dashboard
- 100 hours on permissions system
- 120 hours on email notifications
- 80 hours on file storage
- 150 hours on database architecture
Total: 800 hours. Budget exhausted. Core product logic? Not started.
Option B: Use commodity foundations
- 20 hours integrating authentication (library)
- 30 hours configuring admin dashboard (template)
- 15 hours setting up permissions (library)
- 10 hours connecting email (service)
- 5 hours configuring file storage (service)
- 40 hours on database architecture (using proven patterns)
Total: 120 hours on infrastructure. 680 hours remaining for actual product differentiation.
Same budget. Wildly different outcomes.
Option A burns the entire runway on infrastructure. Option B spends 15% on infrastructure and 85% on the features that make the product valuable.
But founders don’t see this trade-off clearly until it’s too late. By month four, when they realize they’ve spent $60K and still don’t have core functionality working, the path is set. They’re already deep in custom infrastructure. Switching strategies now means rewriting what they’ve built.
So they keep going. And the rebuild happens later, after they’ve proven the market but don’t have capital to scale.
The Framework: Commodity vs Core Budget Discipline
Smart founders ask one question before approving any engineering work: Does this create competitive advantage, or is it solved infrastructure?
That’s the filter. Every feature, every component, every technical decision passes through it.
Competitive advantage: The specific way your product delivers value that competitors can’t easily copy. The unique workflow. The novel data model. The algorithm that makes your recommendation engine better. The integration that unlocks a new use case.
Learned something valuable? We regularly break down these patterns in Codalio’s newsletter. Subscribe to catch the common mistakes founders make and learn how to avoid them.
Subscribe now
Solved infrastructure: Everything else. Login, permissions, payments, email, storage, search, caching, queues, monitoring, deployment. The plumbing that every application needs but no user pays for directly.
Here’s how to apply this:
When an engineer proposes building something, ask: “Is there a production-ready version of this that we could integrate instead?”
If yes: use it. Even if it costs money. Even if it’s not perfect. Because the hours you save on building and maintaining infrastructure can be spent on the features that actually differentiate your product.
If no: ask again. Are you sure? Did you search GitHub, NPM, package repositories, and SaaS tools? Because most things exist already.
If still no: then build it. But assign a maintenance owner. Because custom code isn’t free. It requires ongoing care, updates, bug fixes, and security patches. That’s permanent overhead.
The discipline is simple. The execution is hard. Because it requires saying no to interesting technical work in favor of pragmatic integration work. And developers naturally gravitate toward creation.
That’s why this needs to be a founder-level discipline, not delegated entirely to the engineering team. The founder has to protect the budget by protecting the focus.
How Disciplined Founders Protect Engineering Time
The startups that survive do three things consistently:
1. They inventory commodity components before writing code
Before the first line is written, they list every component the product needs. Authentication. Database. File storage. Notifications. Search. Background processing. Frontend framework. Admin tools.
Then they research existing solutions for each. They don’t assume they need custom implementations. They default to integration unless there’s a specific, documented reason to build.
This saves weeks of effort on decisions that don’t matter. And it forces clarity early about where the actual innovation lives.
2. They timebox infrastructure work aggressively
If authentication integration should take three days, they allocate three days. Not two weeks “just in case.” Because infrastructure work expands to fill available time.
The developer who has three days will integrate a library and move on. The developer who has two weeks will start customizing, then rebuilding, then gold-plating.
Tight timeboxes force pragmatic decisions. And pragmatic decisions preserve runway.
3. They measure engineering time by value delivered, not code written
The question isn’t “how many lines of code did we ship?” It’s “how much closer are we to a product users will pay for?”
Custom authentication code is zero value unless it unlocks something unique. An integrated authentication library that takes two days and works perfectly is high value because it removes a blocker.
Founders who track this ruthlessly find that their teams ship faster and their budgets stretch further. Not because they’re cutting corners, but because they’re cutting waste.
What Codalio Actually Prevents
This isn’t about finding better developers or cheaper rates. It’s about having a system that won’t let you waste money on commodity work.
Codalio was built because we watched this pattern destroy hundreds of products. Brilliant founders. Strong technical teams. All burning capital on infrastructure while the actual product logic stayed undefined.
The platform forces the commodity versus core decision upfront. Before any code exists. Before any budget is committed.
When you scope a product in Codalio, the system automatically identifies which components are commodity and provides them as foundations. Authentication patterns. Backend architecture. Database schemas. Deployment infrastructure. Not as libraries you have to integrate, but as generated, production-ready code that’s already connected.
You’re not paying developers to rebuild login systems. You’re not spending weeks architecting file storage. You’re not debugging permission systems that have been debugged a million times before.
Instead, the entire development budget goes to the 25% that matters. The business logic. The workflows. The features that make your product different from everything else.
That’s not faster development. It’s protected focus. The system prevents you from spending money on solved problems so you can spend it on unique value.
Because the real question isn’t “how do we build software faster?” It’s “how do we stop rebuilding the same software everyone else has already built?”
Codalio answers that by making commodity infrastructure invisible and automatic. So the only thing left to build is the part that actually matters.
Resources
Avoiding the Rewrite by David Heinemeier Hansson Why rebuilding from scratch is usually wrong, and how to think about legacy code. Essential for understanding when custom code is worth it.
Technical Debt: A Consolidated Definition by Software Engineering Institute, Carnegie Mellon The academic foundation for understanding why rebuilds happen and how to prevent them.
If you want to see how Codalio prevents commodity rebuilds on your own idea, try it here .
Learned something valuable? We regularly break down these patterns in Codalio’s newsletter. Subscribe to catch the common mistakes founders make and learn how to avoid them.
Subscribe now