The EBITDA Killer Hidden in the Codebase
You’ve just closed the deal. The thesis was simple: acquire a steady B2B SaaS platform, inject sales rigor, expand margins, and exit in 48 months. But 90 days in, the feature roadmap is stalled. The Founder-CTO tells you the platform is “spaghetti code” and demands a complete rewrite before they can ship the new modules you promised the board.
This is the moment where value creation plans go to die.
Most Operating Partners view technology decisions as engineering problems. They aren't. They are capital allocation problems. Every dollar spent on a rewrite is a dollar not spent on customer acquisition, and worse, it’s a dollar that won’t generate a return within your hold period.
The Tax on Velocity
Let’s look at the numbers. Recent data indicates that technical debt consumes 20-40% of the entire value of a technology estate. More critically for your growth model, developers at debt-laden companies spend roughly 33% of their time purely on maintenance and fixing
The "Grand Rewrite" Fallacy
When a technical leader proposes a "Grand Rewrite" (starting from scratch to build version 2.0), they are essentially asking you to bet the fund's equity on a project with a 70% failure rate. In 2025, digital transformation projects—often code for "rewrites"—failed to meet their original objectives 70% of the time, according to recent industry benchmarks. The reasons are consistent: scope creep, loss of undocumented business logic, and the "second-system effect" where engineers over-engineer the new solution.
For a PE sponsor, the risk is asymmetric. Best case: you get the same functionality you have today, just on a modern stack, 18 months from now. Worst case: you burn 18 months of runway, stall new sales (because you can't sell a roadmap that never arrives), and eventually scrap the project.
The Alternative: The Strangler Fig Pattern
Instead of a rewrite, mandate a refactor and strangle strategy. This involves building new features in a modern microservices architecture that sits alongside the legacy monolith, gradually "strangling" the old system by routing traffic to the new services piece by piece. This approach de-risks the migration and, crucially, allows you to continue shipping revenue-generating features during the transition.
If your Hold Period is under 3 years, never approve a rewrite. If it's 3-5 years, approve it only for specific, high-churn modules. Your goal is not code purity; it is EBITDA expansion and multiple integrity.
The Operating Partner’s Decision Matrix
You need a framework to make these decisions dispassionately. Stop relying on the "gut feeling" of a technical founder who may be incentivized by resume-building rather than enterprise value. Use this decision matrix for every major technology capital request:
1. The Hold Period Test
Does this initiative yield positive cash flow impact within 60% of the remaining hold period? If you are exiting in 24 months, an 18-month infrastructure project is a bridge to nowhere. Prioritize high-velocity, low-effort remediation that improves system stability and reduces churn immediately.
2. The CapEx vs. OpEx Trade-off
Technical debt remediation can often be capitalized, moving it below the EBITDA line. Work with your CFO to structure refactoring projects as capitalizable R&D where compliant. However, be wary of the "OpEx trap" of cloud migration—moving from a depreciated data center (cheap) to an unoptimized AWS environment (expensive) will crush your gross margins. Ensure Unit Economics are modeled before migration begins.
3. The "Kill Switch" Protocol
Every major tech initiative must have incremental milestones every 90 days. If a project cannot demonstrate tangible business value (improved uptime, faster load times, or a shipped feature) in a quarter, kill it. The days of the 2-year "black box" engineering project are over.
