The email landed at 6:52 AM on a Thursday in November. Subject line: "Your upcoming contract renewal — action required." I was halfway through my first coffee and made the mistake of opening it before I was fully awake. Renewal quote: $187,400. Up from $158,800. An 18.3% increase. No explanation beyond a single line about "pricing adjustments aligned with enhanced product value."
I stared at it for a while. Then I forwarded it to our Head of Engineering with three words: "We should talk."
Here's the thing about enterprise SaaS renewals in 2025: vendors know your switching cost better than you do. They have data on how deep their hooks are. They've watched your onboarding, your API call volume, your team's usage patterns. When they send that 18% increase, they're not guessing. They're doing math on your pain threshold. And they're usually right.
We paid the renewal. I want to be honest about that up front, because a lot of these stories skip that part and jump straight to the heroic build-or-migrate narrative. We paid it because we had a product launch six weeks out and no appetite for a platform migration during crunch time. It was the pragmatic call. But it was also the call that finally forced us to have the conversation we'd been avoiding for about fourteen months.
How We Got Here — The Honest Version
The tool in question was our internal workflow orchestration platform — the backbone of our customer onboarding, billing event processing, and a few integrations we'd bolted on over two years. We'd chosen it in early 2023 because the demo was genuinely impressive and the sales process was smooth. That is, I now understand, not a good reason to sign a $158K annual contract. We had done a cursory build-vs-buy analysis, but it was mostly vibes dressed up as a spreadsheet. We wanted to ship fast, the vendor offered quick implementation, and we moved forward.
Over 24 months, we'd accumulated seven internal services that called this platform's APIs, two dedicated team members who were effectively specialists on it, and about 340 hours of onboarding and documentation for new engineers. That's before you even get to the configuration sprawl — 94 custom workflow definitions, 22 webhook configurations, 3 bespoke integrations nobody fully understood anymore.
The 18% renewal was just the moment when the spreadsheet finally got honest with itself.
The Real Build vs. Buy Math Nobody Shows You
After we paid the invoice, I tasked two engineers with a proper cost analysis over three weeks — not "what does a replacement cost to build" but "what does our full true cost of ownership look like, and what does full exit cost look like." Those are different questions, and treating them as the same is how teams make terrible decisions in both directions.
What they came back with was uncomfortable in every direction.
Year one of an internal build was actually more expensive than paying the vendor. I had expected this, but the number — $230,000 when we included honest estimates for engineering time, infrastructure, testing, and a 22% buffer for scope creep — was still a bit deflating when it sat next to $187,000. The case for building was entirely in years two and three, where vendor escalation compounded and our internal costs flattened to maintenance.
By year three, the cumulative vendor spend was $669K. The internal build path: $370K. That's a $299,000 delta, which is roughly two mid-level engineers for a year, or our entire DevOps tooling budget. The math was suddenly very loud.
What the Exit Actually Looked Like (Phase by Phase)
Here's where I want to push back on the "we built it in a sprint and saved a million dollars" narrative that circulates on every tech LinkedIn. The exit plan we put together was a 14-month staged migration. Not glamorous. Very necessary.
Phase one was three months of pure archaeology. We had to catalogue every workflow, every dependency, every implicit assumption baked into 94 configuration objects. One of our engineers called it "defusing a bomb you built yourself and then forgot about." That's accurate. We found three critical workflows that had no documentation anywhere — just tribal knowledge held by one person who'd left eight months earlier. That alone pushed our Phase 2 estimate up by $22,000.
We deliberately kept the build team lean — one senior engineer primary, one mid-level engineer secondary, part-time platform support. We'd seen the trap before where exit projects balloon into their own product and consume the same headcount they were supposed to free up. The constraint was intentional.
⚠ Lesson Learned: The parallel-run phase (months 9–11) was the most expensive thing we didn't budget for properly. Running two systems simultaneously — even with the vendor system in read-mostly mode — cost $11K more than projected due to infrastructure duplication and the engineering overhead of reconciling output diffs. Budget a 15–20% buffer here specifically.
What We Got Wrong, and What We'd Do Differently
I want to resist the temptation to end this as a clean success story, because it wasn't entirely. The migration finished in month 13, one month ahead of schedule, which felt like a win. But we underestimated the productivity dip in Phase 2 — our team's velocity on core product work dropped roughly 19% during the five months of heavy build work. We had accounted for engineering hours but not the context-switching tax that comes with running a migration project as a background thread against normal delivery commitments.
We also overestimated how much of the internal build would be reusable for other purposes. The original case included $40K of "platform investment" that we expected would benefit three adjacent systems. In practice, maybe $14K of that materialized. The rest was too workflow-specific to generalize without another dedicated sprint we haven't had budget for.
The thing I'd tell any engineering leader facing a similar renewal: the real cost of staying is not just the invoice delta. It's the 18% this year, likely another 15–18% next year, plus the compounding complexity cost of a system your team is increasingly resentful of maintaining. That resentment has a dollar value and most TCO models ignore it completely.
If I were doing this analysis again, I'd add a line item called "vendor lock-in drag" — a quarterly estimate of the engineering decisions you avoid, the integrations you don't build, the roadmap features you deprioritize because they're too painful to layer on top of a vendor system you're trying to leave. For us, that number in retrospect was probably another $60–80K over two years of invisible lost opportunity.
The Part That Surprised Us Most
Six months after full cutover, the thing that surprised us most wasn't the cost savings — though those were real. It was what happened to the two engineers who had been de facto specialists on the vendor platform. Both of them, freed from maintaining a system they found intellectually unstimulating, picked up significant new capabilities within a quarter. One moved into distributed systems work she'd been interested in for two years. The other rebuilt our internal alerting pipeline, something we'd needed for a long time but never had bandwidth for.
There's no clean way to put a number on that. But it happened, and I think it's worth naming.
We're now roughly $180K per year ahead of where we'd be on the vendor's escalation curve. The internal system handles our load comfortably and has already needed two meaningful extensions, both of which we shipped in days rather than weeks of vendor support tickets. The exit was slower and more expensive than the bullish projections suggested. It was still obviously the right call.
The 18% renewal wasn't a betrayal by a vendor. It was a clarity tax. We paid the invoice and then, finally, we did the work we should have started doing eighteen months earlier. That, more than anything, is what I'd want someone else in the same situation to hear.