TL;DR — the decision in 60 seconds
Buy commodity capabilities wherever a mature SaaS market already exists. Build the workflows that set you apart, or the ones compliance forces in-house. Most organisations end up somewhere in between, buying the edge and building the core. What matters is the yardstick: decide on five-year total cost of ownership with vendor lock-in exit cost folded in, not the year-1 price that almost always flatters buying.
The decision is rarely a clean either/or. Our enterprise software development architects run the same framework in every CIO evaluation, and here is the shape of it at a glance:
- Buy when a capability is commodity, the SaaS market is mature, and nobody wins a competitive edge from owning it.
- Build when the capability drives revenue or operational advantage, when compliance demands data sovereignty, or when integration debt across a pile of SaaS tools has climbed too high to justify.
- Go hybrid — the route most enterprises take. Buy the commodity layers such as identity, payments and communications; build the differentiating core and the orchestration that ties everything together.
- Run the 5-year TCO. Build almost always looks better over five years than it does in year 1, especially once you model per-seat SaaS pricing against real headcount growth.
Why this decision is different at enterprise scale
For a 50-person SMB, a wrong build vs buy call is survivable. You waste some time or money, you pivot, and you move on. It is a different story for an enterprise carrying 2,000 seats, entrenched ERP integrations and an audit trail that has to stretch back seven years. There, a wrong call turns into multi-year remediation, regulatory exposure, and a name attached to the decision at board level.
Three things change the calculus once you operate at enterprise scale:
Non-linear per-seat pricing
Most SaaS platforms bill per seat or per MAU. At 100 users a $60/seat/month tool costs $72k a year, which nobody argues with. Push that to 3,000 users and the same tool costs $2.16M a year. Volume discounts exist in enterprise contracts, but they rarely go past 20–30%, and minimum annual commitments keep charging you whether or not the seats get used. Custom software behaves differently: once it is built, each extra user costs infrastructure rather than a licence fee.
Integration debt compounds
The average enterprise now runs more than 900 SaaS applications (Okta, 2024). Stitching them together — the point-to-point API connectors, the middleware, the ETL pipelines — routinely costs more to maintain than the applications it connects. Every tool you add is one more integration surface to keep alive. A unified platform collapses that sprawl into a single managed codebase. Our companion article on legacy system modernisation walks through the full remediation framework.
Compliance at enterprise scale is architectural
GDPR Article 28 processor obligations, SOC 2 Type II audit scopes, HIPAA Business Associate Agreements, sector rules such as DORA for EU financial services and FedRAMP for US government — each imposes architectural constraints that most shared-tenancy SaaS platforms meet only halfway. When your compliance team works through a vendor's shared responsibility matrix, whatever gaps are left become your problem to close, usually with custom code that lives outside the vendor's support boundary. At scale, building for compliance from the ground up ends up cleaner and cheaper.
For SMBs evaluating the same question without enterprise-scale constraints, see our companion article custom software vs off-the-shelf.
When should an enterprise buy software?
Buying is the sensible default whenever a capability clears all three of these tests:
- 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, video conferencing — all commodity workflows. Every enterprise handles them much the same way. The SaaS market is mature, data portability is a solved problem (CSV export, standard HRIS APIs), and no one has ever won a deal because their expense tool was proprietary. Buy these, configure them lightly, and resist the pull to customise past the point where you can never leave.
Speed-to-market for non-core capabilities
Sometimes a new product or market needs a capability your engineers have never built: real-time communications, video processing, advanced search. Buying a proven SaaS layer there lets you ship in weeks instead of months. That maths only shifts if the capability later becomes a core differentiator at scale. So start by buying, keep an eye on usage and cost, and schedule a build evaluation around the 18-month mark.
Compliance-heavy SaaS with shared responsibility coverage
Some vendors offer a certified shared responsibility model that genuinely covers your compliance scope — SOC 2 Type II, ISO 27001, HIPAA BAA, PCI-DSS SAQ-D. Where that holds and the residual obligations are small, buying tends to beat running your own certified environment on both time and cost. The load-bearing word is “genuinely”. Audit the shared responsibility matrix itself, not the marketing page that summarises it.
When should an enterprise build custom software?
Building becomes the right call as soon as one or more of these conditions holds:
The capability is a direct competitive differentiator
Think of your proprietary underwriting model, your demand forecasting algorithm, your customer scoring logic. If that capability is the reason customers pick you over a rival, you cannot hand it to a third-party SaaS platform. Do it anyway and the vendor gains architectural visibility into the IP that sets you apart, your delivery slips to their roadmap timeline, and any competitor can license the same platform to close the gap. This is the core you build and own yourself — the code and the roadmap both.
Integration debt has become the primary maintenance burden
Watch where your engineers actually spend their week. Once more of it goes into maintaining API connectors, sync jobs and data transformations between SaaS tools than into building new product, you have hit a build trigger. Over five years, a purpose-built integration and data platform that retires 12 point-to-point SaaS connectors almost always costs less than those connectors did to maintain — and that is before you count how much faster the team moves afterwards. Our article on AI integration in enterprise software covers the architectural patterns that make this tractable.
Vendor lock-in risk is unacceptable
Sometimes a vendor's pricing terms, contract minimums or data-portability limits add up to a risk the organisation simply cannot carry: regulatory audit data trapped in a proprietary format, three-year minimum commitments with 20% annual step-ups, no API for bulk export. When that is the picture, building is what de-risks it. A platform you own can be migrated, archived, audited, and handed to whichever team comes next. The vendor lock-in section below quantifies this.
Data sovereignty and compliance architecture require it
EU GDPR Article 44–49 transfer restrictions, sector rules like MiFID II trade surveillance, NHS data residency and IAEA nuclear-sector requirements, plus national-security considerations in some markets, can make shared-tenancy multi-region SaaS architecturally incompatible from the start. Where data has to stay inside a named jurisdiction, in a defined logical isolation, under a specific audit chain, a compliant platform stops being a preference. It is what the regulator requires.
Vendor lock-in: quantifying the exit cost
Vendor lock-in is not some abstract worry; it is a number that belongs on your balance sheet. Enterprises that skip the modelling tend to meet that number at renewal time, once every scrap of leverage has already moved to the vendor's side of the table.
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 works through a representative decision: a workflow automation and reporting platform sized for 1,000 users in year 1 and growing to 2,500 by year 5. The build figures assume a senior nearshore engineering team delivering over 18 months, backed afterwards by a 2-FTE internal platform 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 |
In this scenario the custom build saves $2.27M over five years before exit costs, and $3.57M–$5.57M once you fold in estimated migration penalties. The crossover — the year where cumulative buy cost overtakes cumulative build cost — lands in year 3 here. Where headcount grows faster, it arrives a year sooner.
These figures sit in line with enterprise software advisory benchmarks from Gartner and IDC across platform categories such as workflow automation, business intelligence and operational data platforms.
The hybrid model: buy core, build edge
Framing “build vs buy” as an either/or is the trap in the first place. For most enterprises the model that actually wins is a structured hybrid: buy commodity capability at the edge, then build the differentiating core and the integration layer that holds it all together.
What to buy in a hybrid model
Identity and access management (Okta, Azure AD), payments (Stripe, Adyen), email delivery (SendGrid, AWS SES), video calling (Daily.co, Twilio), document e-signature (DocuSign, Adobe Sign) — these are solved problems, served by excellent SaaS products with strong developer APIs and real data portability. Lean on them, and your engineers spend their time on the proprietary core rather than rebuilding commodity infrastructure.
What to build in a hybrid model
Build the proprietary workflow engine that encodes your business rules. Build the data model that captures your domain the way no generic SaaS product can. Build the orchestration layer that routes events and data between the commodity services you bought. And build the reporting and analytics layer that shows leadership the metrics your specific business actually runs on — not the canned dashboard bundled with every SaaS contract. More and more, that list now includes AI integration layers that put machine learning to work on your proprietary operational data.
The integration boundary is the key design decision
In a hybrid, the architectural decision that matters most is where you draw the boundary between bought and built. Keep that boundary clean, documented and version-controlled. Every event crossing it should be typed, schema-validated and idempotent. Hybrids fail when teams let bought SaaS products sink deep into the built core — which recreates the very integration debt the model was meant to prevent.
For the pricing mechanics that drive hybrid economics — usage-based versus seat-based, and where each one bites — see our article on SaaS pricing models in 2026.
Decision matrix
Score each platform or capability you are weighing on the matrix below, 1–5 per factor, then add it up. A total above 20 points strongly toward build; below 12 points strongly toward buy; anything from 12 to 20 is where a hybrid assessment earns its keep.
| 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 3 July 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.
