The request that arrives 90 days after close
It usually comes in a one-on-one, not a board meeting. The Founder-CTO closes the laptop, exhales, and says some version of: "Look, before we can ship any of what you promised the LPs, we need to deal with the platform. It's spaghetti. We should rewrite it. Give me eighteen months and a clean codebase." He's not lying, and he's not lazy. He's been carrying that platform like a backpack full of bricks since the seed round, and he genuinely believes a clean slate is the fastest path forward. He is also, almost certainly, wrong about the math that matters to you.
Here is the reframe that separates operating partners who expand multiples from the ones who watch the hold clock run out: a platform decision is not an engineering decision. It is a capital allocation decision, and you already know how to make those. Every engineer-hour poured into rebuilding what already works is an hour not spent acquiring customers, lifting net revenue retention, or shipping the modules that justify the entry price. You wouldn't approve a $4M capex line because the head of operations finds the current machine aesthetically unpleasant. Apply the same discipline here.
And the drag is real, so don't dismiss the CTO's instinct entirely. McKinsey's work on tech debt puts the accumulated liability at 20 to 40 percent of the value of a technology estate before any deliberate paydown. In high-debt portfolios, roughly a third of developer time disappears into maintenance and working around the architecture instead of building anything a customer would pay more for (Byteiota, 2025). That's a tax on velocity, and velocity is the whole growth thesis. The debt is genuine. The proposed cure is what should worry you.
Why the "clean rewrite" is the worst bond in your portfolio
Price the rewrite the way you'd price any instrument. The CTO is asking you to commit eighteen months of equity to a project where the base case is: you arrive at month eighteen owning the exact same feature set you own today, now sitting on a tidier stack. There is no revenue upside in that base case. The upside is entirely the absence of future pain. Meanwhile the downside is fat and well-documented: scope creep, the quiet loss of undocumented business logic that was load-bearing, and the second-system effect where the team gold-plates the rebuild because this time they're "doing it right." Digital transformation efforts in this shape missed their original objectives roughly 70 percent of the time in 2025. You would not knowingly buy a bond with a 70 percent chance of default and zero coupon. That is the rewrite.
The cost of getting it wrong isn't just the burned runway. Poor software quality already drags trillions through the US economy in defects, failed projects, and rework, per CISQ's analysis. A stalled rewrite stacks a second failure on top of the first: the original platform rots while attention sits on the rebuild, the sales team can't sell a roadmap that never ships, and the deferred features you committed to in the value-creation plan slide a full year. Now you're managing two technical debts instead of one.
The alternative I push every portfolio company toward is strangle, not rewrite. Build new capability in modern, well-bounded services that run alongside the legacy system, then route traffic to them piece by piece until the old monolith is doing nothing and you switch it off. The team keeps shipping revenue features the entire time, every increment is reversible, and you never bet the hold on a single big-bang cutover. Tie the decision to the clock: under a three-year hold, I do not approve full rewrites, full stop. On a three-to-five-year hold, I'll fund a rebuild only for the specific modules where the debt is actively bleeding into churn or uptime. The goal was never a clean codebase. It's EBITDA you can defend in the data room.
Three tests to run on the next capital request
You don't need to be able to read the code. You need three tests that let you say yes or no to any major technology spend without deferring to the gut feeling of someone whose incentives may be more about resume than enterprise value.
The hold-clock test. Does this initiative throw off measurable business impact — uptime, churn reduction, a shipped feature customers asked for — inside the first 60 percent of your remaining hold? If you're exiting in 24 months, an 18-month infrastructure project is a bridge that finishes after you've left the building. In that window, fund the high-velocity, low-effort remediation that stabilizes the system and cuts churn now, and table everything that only pays off after your exit date.
The accounting test. Where does this land on the P&L? Some refactoring qualifies as capitalizable R&D, which moves the cost below the EBITDA line — worth modeling with your CFO before you greenlight. But watch the reverse trap: a cloud migration that lifts the company off a depreciated, paid-for data center and drops it into an unoptimized hyperscaler bill converts cheap capex into expensive opex and quietly compresses gross margin. Make sure the unit economics are modeled before a single workload moves, not discovered in the first post-migration board deck.
The stop-loss test. Every initiative ships something demonstrable every 90 days, or you re-scope it. No exceptions, no "the foundational work isn't visible yet." A quarter with no shipped value is your signal to intervene before it becomes a year. The two-year black-box engineering project, funded on faith and a founder's promise, is the single most reliable way to watch a value-creation plan die quietly. The Monday move is simple: pull up the current roadmap and find the largest initiative with no business-visible milestone in the next quarter. That's the conversation to have this week.
