Build vs Buy in 2026: A Decision Framework for SaaS Replacement
AI changed the math on building vs buying internal tools. Here's a no-fluff framework I use with clients to decide what to replace and what to keep paying for.
By Andrii Votiakov on
The build-vs-buy question used to be straightforward: SaaS was cheaper and faster, build was for differentiation only. AI shifted the line. Search, classification, summarisation, extraction, generation — the hard parts of most SaaS tools — are now a few API calls. The 80/20 of many tools can be rebuilt in weeks rather than years.
That doesn't mean you should rebuild everything. But the framework needs an update.
Quick answer
Replace SaaS when (a) the tool costs >$30k/year, (b) you use <30% of the product, (c) the workflow is specific to your business. Keep buying when (a) regulated/compliance-heavy, (b) network effect is the product (Slack, GitHub), (c) commodity workflows you don't differentiate on (payroll, accounting, email).
The framework
Five questions, scored 1-5, summed:
1. What's the annual cost, including seats and overage?
- 1-2: < $10k/year
- 3: $10-30k/year
- 4: $30-100k/year
- 5: > $100k/year
2. How much of the feature set do you use?
- 1: > 70% (you're getting your money's worth)
- 2: 50-70%
- 3: 30-50%
- 4: 15-30%
- 5: < 15% (you're paying for someone else's roadmap)
3. How specific is the workflow to your business?
- 1: Generic, every company does it the same way (payroll, expense management)
- 2: Mostly generic with light customisation
- 3: Mixed
- 4: Mostly custom logic on top of generic primitives
- 5: Genuinely unique to your operations
4. How exposed are you to vendor lock-in?
- 1: Easy to migrate, data is portable, multiple vendors compete
- 2-3: Some friction
- 4-5: High friction (custom workflows in vendor's DSL, proprietary data format, network effect)
5. How much engineering time would the rebuild cost?
- 1: A weekend's work (genuinely)
- 2: A few weeks
- 3: 1-3 months
- 4: 3-6 months
- 5: > 6 months
Score interpretation:
- 5-9: Don't even consider it. Keep buying.
- 10-14: Borderline. Re-evaluate annually.
- 15-19: Investigate. Build a proof-of-concept.
- 20-25: Build. The maths is on your side.
Categories that replace cleanly today
After dozens of these conversations, certain categories almost always score high enough to build:
- Document search and Q&A (Notion AI, Glean, Mendable) — vector DB + LLM API, weeks of work
- Helpdesk triage and autoresponders — classification + retrieval, well-understood pattern; see the Intercom replacement guide for a worked example
- Sales / proposal automation — templated generation with brand voice, days to weeks
- Internal admin panels and dashboards — auto-generated UI on top of your DB; tools like Retool/Internal/Forest let you skip even more
- Workflow automation for high-volume internal flows (Zapier-class) — see the dedicated post on this
- Data scraping and enrichment — Playwright + proxies + LLM extraction beats most vendor APIs at scale
- Internal knowledge bases / wikis with AI search — RAG over your existing docs, no Notion AI needed
- Observability — replacing Datadog with a self-hosted stack is one of the highest-ROI swaps at $20k+/month spend
- Feature flags — see the LaunchDarkly replacement guide for the self-hosted case
- Analytics / event tracking — replacing Segment with self-hosted pipelines follows the same pattern
Categories that almost always stay bought
- Anything regulated: payroll, accounting, expense management, KYC/AML
- Anything compliance-certified: SOC 2 Type 2 attestations are expensive to maintain in-house
- Network-effect products: Slack, GitHub, Linear — value comes from everyone else being there
- Identity and SSO: Auth0 replacement is technically possible but rarely the right call below $50k/year spend
- Email and SMS: replacing Twilio or SendGrid at any volume still carries real deliverability risk — buy unless you have strong reasons not to
- Payments: Stripe is the right answer. Don't build payments.
- Anything where one bug = data loss or financial loss
The hidden costs of building
Everyone overestimates the build, underestimates the maintenance:
- Initial build: typically $20-50k for the categories above
- Hosting and APIs: $200-2,000/month depending on volume
- Maintenance: budget 10-15% of original build cost per year for ongoing ops
- Engineer attention: harder to quantify — is this where you want your engineers' brain cycles?
If you only have 4 engineers and your build queue is full, building anything new is opportunity cost on the rest of the roadmap.
What changed in 2026
The genuinely new factor: embedding models, structured output, and good agentic loops mean you can build many tools in the time it used to take to integrate a SaaS.
A custom helpdesk autoresponder that classifies tickets, routes by team, drafts responses, and posts to Slack: ~2 weeks for a competent engineer using Claude or GPT, ~$300/month to run vs $30k/year for a SaaS equivalent that does 60% as well.
A custom Notion-AI-style search over your internal docs: ~1 week with pgvector + OpenAI embeddings + a basic UI, ~$50/month vs $20/user/month at 50 users = $12k/year.
Done badly, these projects sprawl. Done well — with tight scope and a 6-week deadline — they pay back inside 6-12 months and compound for years.
Realistic numbers
A consolidated audit I did recently for a 60-person SaaS:
- $58k/year on Notion AI: replaced with pgvector + Claude, build cost ~$22k, ongoing ~$1.4k/year. 12-month payback.
- $32k/year on a niche analytics tool: replaced with a custom dashboard on Metabase + dbt models. Build cost ~$8k. Payback in 3 months.
- $44k/year on Zapier (high-volume workflows): replaced with internal queue-based automation. Build cost ~$15k, ongoing ~$200/month. 4-month payback.
- $28k/year on a sales proposal tool: replaced with a Claude-powered template engine. Build cost ~$6k. 3-month payback.
Total: $162k/year saved, $51k build cost. Net first-year saving: $111k. Compounds to $400k+ over three years.
The one we didn't replace: their helpdesk SaaS. Score was 12 — borderline. They use it well, the team's trained, vendor's responsive. Sometimes the best decision is to stop investigating.
If you'd like a no-pressure read on which tools in your stack are worth replacing — and which are not — book a call.