SA-201a · Module 3

Build vs. Buy Analysis

4 min read

Build versus buy is the architecture decision that most directly affects the engagement budget and timeline. Building gives you control and exact-fit. Buying gives you speed and reduced maintenance. Neither is universally correct. The analysis that produces the right answer for the specific engagement is total cost of ownership over the solution lifecycle — not just the implementation cost.

  1. Implementation Cost Build: development hours times hourly rate. Buy: license cost plus integration effort. This is the number most people compare — and it is the least useful one because it captures only the first phase of a multi-year commitment.
  2. Maintenance Cost Build: ongoing development, bug fixes, security patches, dependency updates. Buy: license renewal, vendor relationship management, feature requests through vendor channels. Maintenance cost over 36 months typically exceeds implementation cost for custom builds. For purchased solutions, it is predictable and bounded.
  3. Opportunity Cost Build: the time your team spends building and maintaining this solution is time not spent on core product development. Buy: the features you need but the vendor does not provide is a constraint on your product roadmap. Opportunity cost is the most commonly omitted factor in build-vs-buy analysis, and it is often the largest.
  4. Exit Cost Build: the cost of migrating away from your custom solution if requirements change. Buy: the cost of migrating away from the vendor if the relationship ends. Vendor lock-in is real, but so is custom-code lock-in. Both create exit costs. Estimate both before committing.

Do This

  • Evaluate total cost of ownership over 36 months, not just implementation cost
  • Include opportunity cost — what your team cannot build while they are building this
  • Factor exit cost for both options — custom code and vendor solutions both create lock-in
  • Default to buy for commoditized capabilities and build for competitive differentiators

Avoid This

  • Compare implementation cost only and declare the cheaper option the winner
  • Build because "we can build it better" without quantifying the maintenance commitment
  • Buy because "it is faster" without evaluating the feature gap against your requirements
  • Ignore exit cost — the cheapest solution now may be the most expensive solution to leave