Start with the Differentiation Test
Begin by asking whether the capability creates durable advantage. Payroll processing, single sign-on, and email delivery are commodity capabilities: buying them is almost always cheaper and safer than building. Pricing engines, dispatch algorithms, and clinical triage rules may encode how the business actually competes, and those deserve an owned implementation. Score each candidate capability on strategic value and operational criticality, then reserve custom builds for the small quadrant where both are high.
A useful counter-question is what happens if a competitor buys the same product. If the answer is nothing changes, the software is unlikely to be the differentiator. If the answer is that your operating model disappears, the capability sits close to the core. Document the answer in one paragraph per capability; the exercise takes an afternoon and prevents a year of speculative engineering.
- Commodity, regulated, or fast-moving: buy and integrate.
- Differentiating but stable: build once, maintain deliberately.
- Differentiating and changing weekly: build and staff a product team.
- Unclear: run a time-boxed pilot before committing budget.
Price the Full Ownership Lifecycle
Initial build cost is the smallest number in the model. Add hosting, observability, dependency upgrades, security patching, on-call cover, and the product changes that arrive every quarter. A common planning ratio is one hour of maintenance for every three to five hours of build in year one, rising whenever a framework major version lands. A 600-hour build is therefore a two-person commitment across the following year, not a one-off invoice.
Compare that against a subscription with a realistic five-year view, including implementation, data migration, and the integration work that no vendor quote includes. Add the switching cost of leaving: exports that lose relationships, custom fields that do not map, and retraining. The honest comparison is total cost of ownership across the same horizon for both options, with the same integration labour counted on each side.
Assess Integration and Exit Costs
Systems rarely fail on features; they fail on integration. Count the number of systems the new capability must exchange data with, and check whether each offers a supported API, webhooks, or only a nightly file drop. A vendor that covers 80 percent of requirements but offers no webhook forces polling and reconciliation work that can exceed the price of a custom build. Integration surface is a first-class part of the buy decision.
Plan the exit before signing. Insist on a documented data model, a bulk export that preserves identifiers, and the right to run the product for a defined wind-down period. Ask what happens to custom configurations on renewal. If the answer is that they live only in the vendor environment, the switching cost is effectively unbounded and the apparent savings are borrowed against a future migration.
Decide with a Staged Commitment
Convert the decision into a sequence of gates rather than a single irreversible vote. Gate one validates the problem with interviews and a prototype. Gate two delivers a thin vertical slice to real users behind a feature flag. Gate three funds the broader rollout only if adoption and error budgets support it. At each gate, a stop is a successful outcome because it costs less than the next stage would have.
Attach explicit numbers to the gates: activation rate, task completion time, error rate, and support ticket volume. A pilot that cannot name its success metrics will drift into an open-ended build. Time-box discovery to six weeks, and require the team to present both a build and a buy option at the end of it, each with a costed twelve-month plan.
- Gate one: problem validated with five to eight target users.
- Gate two: thin slice in production behind a flag.
- Gate three: rollout justified by measured adoption.
Make the Decision Reversible
Prefer architectures that keep the option open. Isolate vendor SDKs behind an internal interface, keep canonical customer and product identifiers under your control, and store integration payloads so they can be replayed. These habits add modest cost and turn a future migration from a rewrite into a port. Reversibility is worth more than a marginal feature when the contract runs for several years.
Revisit the decision annually against the original assumptions. Vendors get acquired, pricing models change, and internal delivery capacity grows. A decision that was correct for a ten-person company may be wrong at two hundred. Write the assumptions into a short architecture decision record so a future team can see why the choice was made and whether the reasoning still holds.