The math changed while nobody was looking
Five years ago, the answer was almost always buy. Custom software was expensive. Engineering talent was scarce. Vendors had a ten-year head start on features you would spend two years building.
Then Claude Code, Cursor, and Copilot arrived. A small team with the right tools now ships in a quarter what used to take a year. The cost curve on building has fallen faster than any SaaS vendor has cut their prices. Teams are noticing.
This is the vibe coding era. Engineering leaders who signed three year contracts in 2022 are looking at renewal quotes and asking a different question. Not "can we build this" but "should we own this."
This post is a practical framework for answering that.
When replacing a legacy vendor makes sense
Not every vendor is worth replacing. The ones that usually are share a few traits.
The workflow is core to your business. If the vendor runs a process that defines how you make money, you pay a rent that compounds forever. CRM for a sales org. Claims adjudication for a health plan. Trade execution for a fund. Owning it means owning the roadmap.
Your usage is a bad fit for their pricing model. Per-seat pricing punishes teams that want every engineer and analyst to have access. Per-API-call pricing punishes teams that want to build agentic workflows. If you are paying for a model that no longer matches how you use the product, the vendor's incentives are not aligned with yours.
Your data is leaving your environment. Every document, prompt, and record sent to a SaaS vendor is a data boundary crossing. For a regulated fund or a healthcare platform, this is not a minor line item. It is a compliance surface area that grows with your usage.
The vendor is the one using AI on your data. A growing pattern. You send documents to a vendor. The vendor runs their own LLM calls on your data. Maybe they train on it. Maybe they do not. You cannot always tell. You are paying someone else to do AI work on your data, and the value accrues to them.
If two or three of these apply, the replacement math is probably worth running.
The replacement math, written out
Teams get this wrong in both directions. They underestimate the cost of building because the initial demo is easy. They overestimate the cost because they imagine a full rewrite of a ten year old product. Neither is right.
Here is the cost model that actually works:
Initial build cost. Not "how long would it take to rebuild the whole vendor." How long to ship the 20 percent of functionality you actually use. For most teams this is four to twelve engineering weeks with modern AI tooling. Be honest about which features matter.
Ongoing maintenance. The part teams forget. A system you own is a system you maintain. Plan for one engineer at 20 to 30 percent time, indefinitely. For smaller systems this can be less, but it is never zero.
Infrastructure and inference. Hosting, storage, LLM API calls. Usually 10 to 30 percent of the equivalent SaaS contract, but can be higher for inference-heavy workloads. Model this with real usage numbers, not hand-waves.
Compliance and audit. If the workflow touches regulated data, you are inheriting compliance work the vendor used to absorb. Budget for SOC2 scope expansion, HIPAA controls, or ISO 42001 if you ship AI features externally.
Opportunity cost. The hardest number. The engineers building this are not building something else. Be specific about what that something else is.
Add those up and compare to the three-year fully-loaded contract cost, not the first-year sticker price. Most vendors bake in significant year-over-year increases. The honest comparison is multi-year.
The monitoring question nobody asks in the demo
The biggest reason in-house builds fail is not the build. It is the year after the build.
A vendor absorbs the work of making the system keep working. When their LLM starts hallucinating a new field, their team catches it. When a model update changes output formatting, their team handles the migration. When a compliance standard updates, their team ships the control.
If you own the system, you own that work. Which means you need to stand up the infrastructure to do it.
At minimum, an in-house AI system needs:
- Evals that run on every change. A fixed test set of inputs and expected behaviors. Ideally run on every commit and before every model swap.
- Production monitoring. Latency, error rate, cost per request, output distribution. Dashboards your team will actually look at.
- Feedback loops. Users flag bad outputs. Flagged outputs feed into evals. Evals catch regressions before the next release.
- Model version control. Which model version served which request. When a vendor deprecates a model, you want to know what will break before it breaks.
This is not optional. It is the difference between an in-house system that is an asset and one that becomes technical debt three months after launch.
What the path actually looks like
A typical legacy-vendor replacement, for most mid-sized teams, is shaped like this:
Week one. Scope. Which 20 percent of the vendor's functionality do you actually use. Which workflows are core. Which data paths touch regulated systems.
Weeks two through four. Build the first vertical slice. One workflow, end to end, with real data. Evals in place from day one. Monitoring wired up.
Weeks five through eight. Expand coverage. Add the next workflows. Migrate users. Run parallel with the vendor.
Weeks nine through twelve. Cut over. Retire the vendor contract at renewal. Hand off to the in-house team or keep the engineering partner on to iterate.
Fast, but not reckless. The evals and monitoring setup in week one is why the cut over in week twelve is not terrifying.
When not to replace
For the sake of honesty.
Commodity workflows. Payroll, standard accounting, email sending, calendar scheduling. Vendors have scale advantages here that AI tooling does not erase. Do not rebuild QuickBooks.
Heavily integrated ecosystems. If the vendor's value is their network of other integrations and you would lose that on migration, the cost is not the build. It is the loss of the ecosystem.
When the vendor is cheap and works. Not every contract is worth renegotiating. If you are paying a small amount for something that works, leave it alone and build where the leverage is bigger.
The vibe coding era did not make every vendor replaceable. It made some of them replaceable that were not before. The skill is knowing which.
The question to ask before the renewal
Next time a legacy vendor sends a renewal quote, run this short version of the framework.
- Is this workflow core to our business, or a support function.
- What does a three year fully-loaded cost comparison look like.
- What is the 20 percent of their functionality we actually use.
- What would evals and monitoring look like if we owned it.
- Who would build it, and what would they not be building instead.
If the answers point toward building, the worst thing you can do is sign the renewal and revisit next year. By then the build math will be even better, and the contract will be even harder to unwind.
The teams getting this right are moving now.
Kai Token leads AI systems engineering at Fraktional, where teams build in-house AI systems without giving up the rigor that keeps auditors and boards happy.
