SaaS vs Build: Total Cost and Exit Readiness

Compare SaaS, custom software and hybrid options using a common scope, explicit cost units, capacity tradeoffs, acceptance tests and an executable exit plan.

trigger="A new capability, renewal or material vendor constraint requires a buy, build, hybrid or defer decision." owner="The product sponsor owns the decision; finance validates cost treatment and engineering owns delivery and operation." participants={["Product sponsor", "Engineering owner", "Finance partner", "Security/data owner", "Procurement or legal owner"]} prerequisites={["A bounded capability and accepted user outcomes", "Comparable vendor quotes and an engineering estimate", "Demand scenarios and an agreed comparison period", "Data, integration, operating and exit requirements"]} outputs={["Option scorecard and assumption register", "Separated cash, resource and opportunity-cost views", "Proof-of-fit and export-test results", "An approved decision with stop and review triggers"]} doneWhen={["Each viable option meets mandatory requirements", "Units and overlapping costs are reconciled", "The selected option has an operating owner and tested recovery path", "Decision makers understand the downside and exit constraints"]} />

Compare the same accepted capability

A subscription and an engineering estimate rarely describe the same scope. One may include support, audit features and recovery; the other may describe only a first release. Fix that mismatch before comparing totals.

This playbook produces a decision record for one capability. It includes buying SaaS, building software, combining the two, and deferring the work. A strategic capability can use purchased infrastructure. An internal tool can justify a custom build when its constraints warrant it. Neither the company's revenue nor a universal annual spend threshold decides the answer.

The product sponsor writes the required outcomes and the latest useful delivery date. The engineering owner adds the work needed to keep those outcomes operating after launch. A custom system remains dependent on libraries, infrastructure, people and knowledge; “we own the code” does not make exit or maintenance free.

1. Establish mandatory requirements and viable options

Separate requirements that can disqualify an option from preferences that can be traded. Security, data handling and regulatory applicability need the relevant owner's assessment. Do not assume that self-hosting automatically satisfies them.

| Requirement | Evidence to request | Decision owner | |---|---|---| | User workflow | A representative task completed with real constraints | Product | | Integration | Tested API limits, failure behavior and required data access | Engineering | | Data handling | Approved locations, access, retention, export and deletion behavior | Data/security | | Availability and recovery | Recovery objectives, dependency limits and tested fallback | Service owner | | Commercial terms | Dated quote, usage basis, renewal, termination and support scope | Finance/procurement | | Operability | Named support, incident and maintenance responsibilities | Engineering leadership |

Include a hybrid option when the differentiating part can be separated from commodity services. Record the new integration and operating burden it creates. A hybrid is not automatically the cheapest compromise.

Gate: eliminate options that fail a mandatory requirement unless the accountable owner explicitly changes that requirement. Do not hide a failed security or recovery requirement inside a weighted average.

2. Use a cost ledger with consistent units

Finance chooses the comparison period, currency, tax treatment and treatment of capital or financing. Use the same scope and demand assumptions for every option. Preserve quotes and estimate dates.

Cost row:
  Option / period / cost category:
  Quantity:
  Quantity unit:
  Unit price and currency:
  Calculation:
  One-time or recurring:
  Cash cost or internal resource allocation:
  Source, date and confidence:
  Assumptions and overlapping rows:

Engineering effort must use matching units. For example, estimated working days multiplied by productive hours per day gives hours; multiply those hours by a loaded hourly rate. State the productive-hours assumption. Do not multiply days directly by an hourly rate.

For SaaS, include subscription or usage charges, implementation, integration development, identity and security configuration, training, support, ongoing administration, vendor-change work and exit costs. Renewal increases and discounts come from terms or named scenarios, not an assumed industry percentage.

For a build, include discovery, design, implementation, migration, testing, security review, infrastructure, monitoring, incident response, documentation, maintenance and eventual replacement. Estimate recurring work from an operating backlog and staffing model. A fixed percentage of development cost is not evidence of future maintenance effort.

Gate: another reviewer can reproduce each total from the ledger without guessing units or inclusions.

3. Separate money, capacity and opportunity cost

Use three views rather than one inflated total:

| View | Purpose | Avoid | |---|---|---| | Incremental cash | Additional payments caused by the decision | Treating all existing payroll as new cash expenditure | | Resource consumption | Engineering and operating capacity assigned to the option | Counting the same hours twice under development and maintenance | | Opportunity scenario | Value of specific work delayed or displaced | Adding the same salary allocation again as “opportunity cost” |

Existing engineers still consume scarce capacity even when payroll does not change. Show that capacity in engineer-hours or an agreed internal allocation. Then identify the actual alternative work displaced, its timing and the uncertainty in its expected benefit.

If a finance-approved economic model includes forgone contribution, explain whether it is gross or net of relevant costs and which cost rows overlap. Do not add a speculative revenue estimate to a full labor allocation without reconciling the model. Keep uncertain opportunity scenarios visible even when the team cannot responsibly reduce them to one number.

Use a common accepted-work unit where useful, such as cost per active operator or successfully processed transaction. The FinOps Foundation's unit-economics guidance connects cost measures to the business outcome being served. A cheaper unit that fails the required workflow is not comparable.

4. Test the assumptions that could reverse the decision

The engineering owner identifies the largest uncertainty in each viable option. Run a bounded proof of fit: one difficult integration, one representative workflow, one access-control case and one export/restore exercise. Use permitted data and keep test actions away from production effects.

"type": "flow", "title": "Buy or build decisions need evidence before commitment", "steps": [ ], "caption": "A failed proof of fit returns the option to revision. Contract negotiation or prototype momentum should not bypass the acceptance criteria." }} />

Model low, expected and high demand with explicit drivers. Also test delivery delay, a vendor feature gap, support load and an earlier-than-planned exit. Report which assumption changes the preferred option. There is no need to assign invented probabilities when the available evidence supports only a range.

Keep sunk costs separate from the next decision. Money already spent may explain the current situation, but it does not make an unviable option better going forward.

5. Verify portability at the data and workflow level

An abstraction can isolate provider-specific code, but it cannot erase differences in identity, permissions, billing semantics, query behavior or data models. Introduce an interface where it protects a real boundary. Do not promise a fixed number of days saved by wrapping an SDK.

For each provider, inventory exportable data, identifiers, credentials, history, configuration, attachments and workflow state. Test whether the receiving system can import and reconcile them. A CSV export is not proof that the business process can continue.

Payment migration needs particular care. Stripe documents a secure card-data export process to an eligible receiving processor, with exclusions. That disproves a blanket claim that all tokenized payment data is non-portable. It does not mean Stripe object IDs work at another provider or that subscriptions and payment history move through the same export.

Have the payment owner confirm receiving-provider support, supported payment methods, identifier mapping, mandates, recurring billing and reconciliation. Use the provider-supported secure transfer process. Do not download raw card data into an ordinary engineering workspace to test portability.

6. Negotiate the operating contract, then stage adoption

Procurement reviews the actual renewal notice period, usage bands, overages, price changes, termination rights, support, data export and deletion terms. Start early enough to preserve a viable alternative. No universal negotiation discount or lead time is assumed.

For a build, the equivalent operating agreement names the service owner, maintenance capacity, support coverage, accepted release scope and funding for security and dependency updates. A prototype has not established these commitments.

Adopt the selected option through a bounded cohort. Maintain the current authoritative system where possible until the acceptance gates pass. Record who owns writes, how duplicate processing is prevented, and how new records will return to the previous workflow if the trial fails.

| Adoption failure | Immediate response | Recovery condition | |---|---|---| | Required workflow fails | Stop expansion and keep the accepted current process | Gap resolved or a new decision approved | | Integration times out after a write | Record unknown outcome and query authoritative status | Effect reconciled before retry | | Cost exceeds the approved demand scenario | Restrict expansion and review scope or terms | Revised forecast and owner approval | | Vendor export lacks required records | Retain source access and pause decommissioning | Export/import and reconciliation test passes | | Custom build cannot meet the operating commitment | Reduce scope, extend the current service or reconsider buying | A funded owner can support the accepted capability |

A contract may prevent immediate financial rollback even when traffic can be moved. A database or workflow may require reconciliation before operational rollback. Keep those limits separate.

7. Compare security and assurance responsibilities explicitly

For SaaS, record the exact product, edition, deployment region, data flows, identity integration, administrative roles, subprocessors where relevant, audit evidence, encryption and key options, retention, deletion, incident notification and support access. A provider assurance report covers a stated scope and period; it does not prove that the customer's configuration or workflow meets every requirement.

For a build, record the equivalent responsibilities: secure development, dependency and artifact controls, infrastructure, access review, vulnerability response, logging, backups, incident support and evidence production. NIST's Secure Software Development Framework can inform the practices required for internally developed software. It is not a certification and does not make a custom build automatically safer.

Create a responsibility matrix for each mandatory control. Mark provider, customer, shared and unresolved responsibilities. Test customer-controlled settings and application authorization. A vendor may authenticate the user while the integration still grants the wrong tenant or exports more data than intended.

Review privileged support and emergency access. Confirm how vendor access is approved and logged, how internal administrators are controlled, and what happens when identity federation is unavailable. For a build, test the equivalent break-glass and revocation process. Do not give the custom option an unrealistically perfect future control while judging the SaaS option from its current limitations.

8. Maintain a build operating backlog before approving construction

Create the backlog for the first accepted release and the following operating period. Include dependency updates, platform upgrades, security response, data lifecycle, support, monitoring, incident work, capacity, documentation, accessibility, admin tools, integrations and recovery tests. Estimate ranges with named owners, not a flat percentage of initial development.

Distinguish product differentiation from commodity obligations. The team may want to build a unique workflow but still purchase identity, payments, messaging or infrastructure. Price and govern the hybrid boundaries. Each purchased component introduces service dependency and exit work; each custom component introduces maintenance and succession work.

Run a support tabletop. Give the proposed owner a failed job, denied user, incorrect bill, data export request and unavailable dependency. Determine which evidence, permissions and escalation are needed. If the build estimate has no capacity for those paths, it does not cover the accepted capability.

Include knowledge concentration. Document how a second engineer deploys, diagnoses and recovers the system. A custom build whose operation depends on one person has a risk and capacity cost even if source code ownership is complete.

9. Perform an exit rehearsal before long-term commitment

For SaaS, export a representative set of non-production data, configuration, attachments, identities and workflow state using supported interfaces. Import or reconstruct it in a target that proves the essential business process. Record missing history, identifier changes, rate limits, manual steps, provider assistance, transfer cost and elapsed time.

For a custom build, rehearse replacement of one infrastructure or supplier dependency and restoration from approved backups. Verify code and infrastructure access, build reproducibility, keys, data schema, deployment, support ownership and license obligations. “We have the repository” is not a complete exit plan.

NIST SP 800-144 provides guidelines on security and privacy in public cloud computing, including the need to understand provider responsibilities and risks. Use it to frame due diligence appropriate to the current service, while checking modern product capabilities and contractual terms directly.

Define exit triggers: failed mandatory capability, unacceptable renewal, provider retirement, support deterioration, data-location change, recurring incident, internal ownership loss or strategic product change. Attach authority and lead time. An exit option is useful only when the organization can detect the trigger and fund the transition.

Do not delete the source or terminate the contract immediately after a successful sample export. Complete data and workflow reconciliation, retention, audit and customer obligations first. Keep exact decommission targets and approval.

10. Review the decision under downside scenarios

Present at least three demand scenarios and two adverse operating scenarios. Demand may be lower, expected or higher than forecast. Adverse cases might include a delayed custom release, a vendor price change, a key integration redesign, unexpected support load or a required security control missing from the initial scope.

Show which option changes under each scenario. Separate cash exposure, engineering capacity, service risk and delivery timing. Do not collapse them into one weighted score unless decision owners agree the weights and understand what a hard requirement can disqualify.

Record the point of irreversibility. A signed multi-year contract, migrated authoritative data, new customer promise or retired internal system can limit the next move. Require the corresponding procurement, data, product and engineering approvals before crossing it.

The sponsor's decision can buy, build, compose, defer or narrow the capability. Preserve rejected options and the assumption that would justify reopening them. A proof of concept should not quietly become a production commitment because time was spent on it.

11. Verify benefits after adoption

After representative use, compare the accepted capability, demand, support effort, service behavior and actual cost with the decision record. Distinguish a negotiated discount, avoided future capacity, realized cash change and internal capacity consumed. Report migrations and parallel running separately.

Ask users whether the workflow meets the mandatory outcome and where manual work moved. Lower subscription spend with more reconciliation or support effort may be a worse total result. A custom tool delivered on time may still fail if ownership and recovery remain unclear.

Set the next review trigger against renewal, demand, missing capability, support load, security change or operating-owner capacity. Close temporary integrations, exports, credentials and duplicate data only after their obligations are resolved.

Decision record and acceptance checklist

Capability / sponsor / decision date:
Mandatory outcomes and latest useful delivery:
Options considered, including hybrid and defer:
Quoted and estimated scope:
Cash, resource and opportunity views:
Demand and downside scenarios:
Proof-of-fit, security and portability results:
Selected option and reasons:
Operating owner, budget and support commitment:
Stop conditions, exit path and known irreversibility:
Approvers and next review trigger:

"All viable options cover the same accepted capability", "Cost rows have consistent units, dates and no unexplained overlap", "Displaced work is identified separately from labor cost", "The most consequential assumptions were tested", "Data export and import were verified beyond a vendor promise", "Adoption has an authoritative write owner and reconciliation path", "Commercial commitments and operational rollback limits are explicit", "The sponsor approved residual risk and a review trigger" ]} />

Limitations and next action

This method does not supply market rates, legal conclusions or guaranteed savings. Quotes, workforce costs, provider support and business priorities change. Finance and legal owners must approve the model and terms appropriate to the organization.

Reopen the decision when mandatory requirements, demand, vendor terms or maintenance capacity change. For a focused technology-stack evaluation, bring the ledger and the assumptions most likely to reverse the result.

Primary references