TL;DR — the decision in 60 seconds
The enterprise build vs buy decision is not binary. Here is the framework at a glance:
- Buy when the capability is a commodity, a mature SaaS market exists and the workflow is not a competitive differentiator.
- Build when the capability is a direct source of revenue or operational advantage, when compliance requires data sovereignty, or when integration debt across multiple SaaS tools has become unacceptably high.
- Hybrid is the answer for most enterprises: buy commodity layers (identity, payments, communications), build the differentiating core and integration orchestration.
- 5-year TCO almost always makes build look better than it does in year 1 alone — particularly when modelling per-seat SaaS pricing at enterprise headcount growth.
Why this decision is different at enterprise scale
For a 50-person SMB, a wrong build vs buy call is recoverable. You spend too much time or money, you pivot, you move on. For an enterprise with 2,000 seats, entrenched ERP integrations and an audit trail requirement stretching back seven years, a wrong call means multi-year remediation, regulatory exposure and leadership accountability.
At enterprise scale, three factors change the calculus entirely:
Non-linear per-seat pricing
Most SaaS platforms price per seat or per MAU. At 100 users a $60/seat/month tool costs $72k/year — reasonable. At 3,000 users the same tool costs $2.16M/year. Enterprise contracts may offer volume discounts, but rarely more than 20–30%, and minimum annual commitments lock you in regardless of actual utilisation. Custom software has a flat maintenance cost curve: once built, adding users costs infrastructure, not licence fees.
Integration debt compounds
The average enterprise runs 900+ SaaS applications (Okta, 2024). The integration layer between those applications — point-to-point API connectors, middleware, ETL pipelines — routinely costs more to maintain than the applications themselves. Every new SaaS tool added is a new integration surface. Building a unified platform reduces integration debt to a single managed codebase. Read our companion article on legacy system modernisation for the full remediation framework.
Compliance at enterprise scale is architectural
GDPR Article 28 data processor obligations, SOC 2 Type II audit scopes, HIPAA Business Associate Agreements and sector-specific regulations (DORA for EU financial services, FedRAMP for US government) impose architectural constraints that most shared-tenancy SaaS platforms satisfy only partially. When your compliance team reviews a vendor's shared responsibility matrix, the gaps that remain are your problem to close — often with custom code that sits outside the vendor's support boundary. Building for compliance from the ground up is cleaner and cheaper at scale.
For SMBs evaluating the same question without enterprise-scale constraints, see our companion article custom software vs off-the-shelf.
When to buy
Buying is the right default for any capability that meets all three of these criteria:
- The workflow is not a direct competitive differentiator — your competitors use the same category of tool and gain no advantage from it.
- A mature SaaS market exists with multiple credible vendors, established integration ecosystems and reasonable data portability.
- The per-seat cost at projected 5-year headcount is lower than the 5-year build + maintain cost including a 2-FTE platform engineering team.
Commodity capabilities: buy by default
HR and payroll, basic CRM, corporate travel, expense management, email and calendar infrastructure, video conferencing — these are commodity workflows. Every enterprise does them the same way. The SaaS market is mature, data portability is established (CSV export, standard HRIS APIs) and no enterprise gains competitive advantage from having a proprietary expense tool. Buy these, configure them minimally, and resist the urge to customise beyond the point of no-return.
Speed-to-market for non-core capabilities
When a new product or market requires a capability your engineering team has never built — real-time communications, video processing, advanced search — buying a proven SaaS layer lets you ship in weeks rather than months. The calculus changes if and when that capability becomes a core differentiator at scale. Start with buy, monitor usage and cost, and run a build evaluation at the 18-month mark.
Compliance-heavy SaaS with shared responsibility coverage
When a SaaS vendor offers a certified shared responsibility model that genuinely covers your compliance scope — SOC 2 Type II, ISO 27001, HIPAA BAA, PCI-DSS SAQ-D — and the residual compliance obligations are minimal, buying is often faster and cheaper than maintaining your own certified environment. The qualification is “genuinely covers”: audit the shared responsibility matrix, not the marketing page.
When to build
Building is the right decision when one or more of the following conditions apply:
The capability is a direct competitive differentiator
Your proprietary underwriting model, your demand forecasting algorithm, your customer scoring logic — if this capability is why customers choose you over a competitor, you cannot hand it to a third-party SaaS platform. The vendor now has architectural visibility into your differentiating IP, you operate on their roadmap timeline, and any competitor can buy the same platform and close the gap. Build the differentiating core. Own the IP. Own the roadmap.
Integration debt has become the primary maintenance burden
When your team spends more engineering time maintaining API connectors, sync jobs and data transformations between SaaS tools than building new product capability, you have a build trigger. The 5-year cost of a purpose-built integration and data platform that replaces 12 point-to-point SaaS connectors is almost always lower than the ongoing integration maintenance cost, even before you account for the speed improvement in the engineering team. See our article on AI integration in enterprise software for the architectural patterns that make this tractable.
Vendor lock-in risk is unacceptable
When a vendor's pricing terms, contract minimums or data portability limitations create a risk that the organisation cannot accept — regulatory audit data locked in a proprietary format, minimum 3-year commitments with 20% annual step-ups, no API for bulk data export — building is the de-risking option. The custom platform you own can be migrated, archived, audited and handed to any future team. See the vendor lock-in section below.
Data sovereignty and compliance architecture require it
EU GDPR Article 44–49 data transfer restrictions, sector-specific regulations (MiFID II trade surveillance, NHS data residency, IAEA nuclear sector requirements) and national security considerations in certain markets make shared-tenancy multi-region SaaS architecturally incompatible. When data must remain in a specific jurisdiction, in a specific logical isolation, with a specific audit chain, building a compliant platform is not a choice but a regulatory requirement.
Vendor lock-in: quantifying the exit cost
Vendor lock-in is not a hypothetical risk. It is a quantifiable liability that belongs on your balance sheet. Enterprises that skip this modelling consistently discover it at renewal time, when the leverage has already shifted entirely to the vendor.
A complete lock-in exit cost model includes five components:
- Data extraction and migration: engineering hours to export all data from the vendor's proprietary schema to a portable format, validate integrity, transform and import to the replacement system. For an enterprise with 5 years of operational data, this is typically $150,000–$500,000.
- Integration rewiring: replacing all downstream integrations that call the vendor's APIs with calls to the replacement system. Multiply the number of integration points by 40–120 hours each.
- Retraining and change management: for platforms with high user engagement (ERP, CRM, ITSM), budget 40–80 hours of change management per 100 affected users.
- Contractual minimums and termination fees: read every contract. Most enterprise SaaS agreements include 90-day termination notice, minimum annual commitment clauses and sometimes explicit “convenience termination” fees of 50–100% of remaining contract value.
- Business continuity risk: the cost of running both the old and new system in parallel, plus the risk premium for the period where neither is fully operational.
5-year TCO at enterprise scale
The table below compares a representative enterprise platform decision: a workflow automation and reporting platform for 1,000 users at year 1, growing to 2,500 users by year 5. Build cost assumes a senior nearshore engineering team delivering over 18 months, plus a 2-FTE internal platform engineering team for ongoing development and maintenance.
| Cost item | Buy (SaaS) 1,000→2,500 seats |
Build (custom) flat maintenance |
Hybrid buy edge + build core |
|---|---|---|---|
| Year 1 — implementation | $480k (licence + setup) | $750k (build) | $520k (build core + SaaS edge) |
| Year 2 — operations | $560k | $175k (maintenance + team) | $260k |
| Year 3 — operations | $700k | $175k | $270k |
| Year 4 — operations | $900k | $180k | $290k |
| Year 5 — operations | $1,100k | $185k | $310k |
| 5-year total (excl. exit) | $3,740k | $1,465k | $1,650k |
| Est. exit cost if migrating off | $2,200k–$3,500k | $150k–$400k | $400k–$900k |
The 5-year TCO advantage of a custom build in this scenario is $2.27M before exit costs and $3.57M–$5.57M including estimated migration penalties. The crossover year — where the buy curve exceeds the build curve in cumulative cost — is year 3 in this model. For platforms with faster headcount growth, the crossover arrives in year 2.
These figures align with enterprise software advisory benchmarks from Gartner and IDC for platform categories including workflow automation, business intelligence and operational data platforms.
The hybrid model: buy core, build edge
The framing of “build vs buy” as a binary choice is itself the conceptual trap. The winning model for most enterprises is a structured hybrid: buy commodity capability at the edge, build the differentiating core and the integration layer that ties it together.
What to buy in a hybrid model
Identity and access management (Okta, Azure AD), payments processing (Stripe, Adyen), email delivery infrastructure (SendGrid, AWS SES), video calling (Daily.co, Twilio), document e-signature (DocuSign, Adobe Sign) — these are solved problems with excellent SaaS products, strong developer APIs and established data portability. Using them lets your engineering team focus on the proprietary core instead of reinventing commodity infrastructure.
What to build in a hybrid model
The proprietary workflow engine that encodes your business rules. The data model that represents your domain in a way no generic SaaS product can. The integration orchestration layer that routes events and data between bought commodity services. The reporting and analytics layer that gives your leadership team insight into the metrics that matter to your specific business — not the canned dashboard that ships with every SaaS contract. Increasingly, this includes AI integration layers that apply machine learning to your proprietary operational data.
The integration boundary is the key design decision
In a hybrid model, the most important architectural decision is where to draw the integration boundary between bought and built components. This boundary must be clean, well-documented and version-controlled. Events flowing across it must be typed, schema-validated and idempotent. The enterprises that fail at hybrid are the ones that allow bought SaaS products to become deeply embedded in the built core — creating exactly the integration debt they were trying to avoid.
For the SaaS pricing mechanics that affect hybrid model economics, including usage-based vs seat-based pricing, see our article on SaaS pricing models in 2026.
Decision matrix
Use this matrix to score each platform or capability you are evaluating. Score 1–5 for each factor. A total score above 20 is a strong signal to build; below 12 is a strong signal to buy; 12–20 warrants a hybrid assessment.
| Decision factor | Buy signal (score 1) | Build signal (score 5) | Your score (1–5) |
|---|---|---|---|
| Competitive differentiation | Commodity; competitors use same SaaS category | Core IP; direct revenue or margin driver | |
| 5-yr TCO (buy vs build) | Buy TCO clearly lower at projected growth | Build TCO lower by year 3 or earlier | |
| Vendor lock-in exit cost | Data portable; exit cost under $200k | Exit cost exceeds $1M; data portability limited | |
| Compliance fit | Vendor certified; residual obligations minimal | Data sovereignty or audit requirements unsatisfiable by SaaS | |
| Integration complexity | Standard connectors available; low integration burden | Deep custom integration required; existing debt already high | |
| Roadmap control need | Vendor roadmap acceptable; no urgent custom feature need | Roadmap must respond to business needs within weeks, not quarters |
FAQ
Should an enterprise build or buy software?
It depends on whether the capability is a competitive differentiator or a commodity. Buy commodity workflows (HR, payroll, basic CRM) where the SaaS market is mature and switching cost is acceptable. Build when the capability is a direct revenue or margin driver, when compliance requires data sovereignty, or when the 5-year build TCO is lower than the SaaS TCO at projected headcount growth. Most enterprises do both via a structured hybrid model.
What is vendor lock-in and why does it matter at enterprise scale?
Vendor lock-in is the state where switching away from a platform costs more than the accumulated value of doing so. At enterprise scale this means proprietary data formats, per-seat pricing that grows non-linearly, contractual minimum commitments and migration costs that can reach $2–5M for a fully embedded enterprise platform. Model the exit cost before you sign a multi-year contract, not at renewal time when all leverage has shifted to the vendor.
Is custom enterprise software worth the cost?
Yes, when applied to the right scope. Custom software is worth the cost when the workflow is a revenue or margin driver, when compliance requirements cannot be met by shared-tenancy SaaS, or when the 5-year custom TCO — including a 2-FTE internal platform team — is lower than the 5-year SaaS TCO at projected growth. For the majority of enterprises running 1,000+ seats on a platform that grows with headcount, the custom build pays back by year 3.
How do I model 5-year TCO for enterprise software?
Build four columns: (1) Buy: year-1 licensing at current seats + years 2–5 at projected growth + integration connectors + customisation; (2) Build: year-1 development + years 2–5 maintenance at 18% of build cost + 2-FTE platform team; (3) Hybrid: reduced build scope + commodity SaaS edge; (4) Exit cost for each option. Take the NPV of each column at your discount rate over 5 years. The option with the lowest NPV, including exit cost, is the correct decision. Do not exclude exit cost — it is the single most underestimated variable in enterprise procurement.
Can we mix build and buy?
Yes — this is the recommended pattern for most enterprises. Buy commodity capabilities (identity, payments, communications, analytics) from mature SaaS providers. Build the differentiating core workflow, proprietary data model and integration orchestration layer. The key design decision is drawing a clean, well-documented integration boundary between the two — and enforcing it. Allowing bought SaaS products to bleed into the built core recreates the integration debt you were trying to avoid.
Last updated 9 June 2026. TCO figures reflect senior nearshore delivery and representative enterprise SaaS pricing for workflow and data platforms at 1,000–2,500 seats. Individual project costs vary. Figures consistent with Gartner and IDC enterprise platform advisory benchmarks for 2025–2026.
