A build-versus-buy decision compares ways to obtain a defined capability, not software in the abstract. Evaluate strategic differentiation, fit, time, total lifecycle cost, integration, security, privacy, reliability, vendor health, operating burden, and exit cost. Include hybrid and defer options, then validate important claims with a proof of concept and references.
Who this is for: Product, engineering, security, finance, and operations leaders choosing how to acquire a product capability.
- Define required outcomes, workflows, service levels, and constraints before evaluating vendors or estimating a build.
- Compare total lifecycle cost and risk under consistent usage and growth scenarios rather than first-year price.
- Plan ownership, data portability, migration, contract controls, and an exit trigger before making the commitment.
Define the capability
State the customer or operational outcome, users, critical workflows, scale, quality threshold, and nonnegotiable constraints. Separate core requirements from preferences and future possibilities. A vague request for 'an analytics platform' encourages feature-checklist comparison; a requirement for governed self-service reporting with row-level access and two-hour data freshness is evaluable.
Ask whether the capability differentiates the product or merely supports it. Differentiation can favor internal control, but it does not automatically require building every layer. Commodity components may be purchased beneath a distinctive workflow. Also include keep-current-state and defer options when the problem does not justify either major path yet.
Compare fit and control
Assess workflow fit, configurability, APIs, data model, performance, availability, accessibility, localization, security, privacy, compliance, and support. Verify vendor claims through documentation, demonstrations using your cases, references, and a time-boxed proof. Record gaps and whether configuration, process change, or custom code would close them.
For a build, examine engineering capability, opportunity cost, maintenance, on-call support, documentation, staffing continuity, and dependency components. Internal ownership offers control only when the organization funds continued operation. Custom code that nobody can safely change is not meaningful strategic flexibility.
Model lifecycle economics
Use consistent scenarios for users, transactions, storage, regions, and growth. Buy costs can include licenses, implementation, integration, overages, support tiers, audits, and price escalation. Build costs can include discovery, development, infrastructure, security, compliance, operations, incident response, upgrades, and the product work displaced.
Model expected, low, and high cases over an appropriate period. Include migration and exit cost for both choices. Avoid treating salaried engineers as free or vendor setup as instantaneous. Finance should review assumptions, while technical and operational owners validate the labor and reliability model.
Decide with an exit path
Scorecards can organize evidence but should not hide decisive constraints inside weighted averages. A vendor that cannot meet a legal data requirement is not rescued by a strong interface score. Write a recommendation with tradeoffs, dissent, unresolved risks, and conditions for approval. Assign accountable owners across contract and technical obligations.
Plan data export, configuration records, interface abstraction where justified, renewal review, service failure response, and migration triggers. Monitor actual cost, reliability, fit, and vendor changes after selection. The decision can change as scale, strategy, vendor terms, or internal capability evolves; retaining evidence makes reevaluation faster.
Choose an identity verification capability
A marketplace needs identity checks before high-value payouts and is considering an internal system or specialist provider.
- Define eligible users, supported countries, review times, error tolerances, privacy duties, appeal, and payout dependencies.
- Assess vendor and internal options against real document cases, APIs, accessibility, manual review, security, and regulatory needs.
- Model three-year volume, integration, operations, false-result support, audits, vendor increases, and internal opportunity cost.
- Run a controlled proof with representative cases and specialist oversight rather than exposing all sellers.
- Recommend a path with contract protections, performance monitoring, data export, appeal ownership, and exit triggers.
Build, buy, or hybrid comparison
Use the same assumptions and evidence standard for every acquisition option.
- Capability: outcome, actors, critical workflows, scale, service level, must-haves, and strategic role.
- Fit and risk: function, integration, data, security, privacy, compliance, accessibility, reliability, and support.
- Economics: implementation, license or labor, infrastructure, operations, growth, incidents, displaced work, and exit.
- Evidence: documentation, proof cases, references, estimates, scenario sensitivity, gaps, and confidence.
- Decision: recommendation, conditions, dissent, owners, contract terms, monitoring, renewal, and migration trigger.
Common mistakes
- Comparing a vendor's subscription price with only the initial engineering estimate for an internal build.
- Buying against a generic feature checklist without testing the organization's critical workflows and constraints.
- Ignoring data portability and exit cost until vendor performance or pricing has already become unacceptable.
Try one
A vendor covers 90 percent of requirements and promises the rest next quarter. How should that promise enter the decision?
A strong answer treats unshipped capability as a risk, verifies contractual commitment and roadmap evidence, and evaluates whether the missing ten percent includes any hard constraint. It models a fallback, customization burden, delay, and exit path. The decision record should distinguish current verified fit from forecast fit and assign an owner to acceptance before dependency.
Sources
- Atlassian product strategy guideOfficial guidance on connecting product vision, market context, goals, and initiatives.
- Atlassian product requirements guideOfficial guidance on collaborative, concise, and testable product requirements.