Build vs buy software is a decision about how to support a business capability. The options usually include configuring an existing product, extending it, connecting several products or commissioning a custom application. Starting with only two options can hide a workable middle route.
Compare the same operating need across every option. A product demonstration and a custom-development feature list are not equivalent evidence. Both need to show how people complete the task, how exceptions are handled and who owns the work afterwards.
Separate the business capability from a preferred tool
Write down the process, participants and important constraints before selecting a platform. For example, a fictional equipment supplier needs its sales team to approve account-specific quotations while protecting branch information. The problem is not initially “we need a new CRM”.
Identify where the process is distinctive and where the business can reasonably adopt an established convention. Thoughtworks' buy/build discussion examines the different consequences of those choices. Use that as a strategic question, rather than assuming a custom build is justified whenever an existing product needs configuration.
Test four routes against the same workflow
| Route | Evidence to request | Ownership question |
|---|---|---|
| Buy and configure | Representative tasks in a trial environment | Who maintains settings, licences and permissions? |
| Extend a product | Supported extension points and upgrade behaviour | Who supports the extension when the product changes? |
| Integrate products | Data contracts and failure/reconciliation tests | Who resolves disagreement between systems? |
| Build an application | Scoped workflow, acceptance checks and operating plan | Who maintains code, infrastructure and user support? |
These routes can coexist. A company might buy accounting software, configure a CRM and build a small approval tool. Evaluate each connection and its ongoing responsibility instead of treating the resulting system as one indivisible product decision.
Use a CRM example to expose fit gaps
For the equipment supplier, prepare a quotation containing two branches, an approval limit and a customer-specific discount. Ask each candidate product to demonstrate the permitted and forbidden actions. Include a rejected quote, a user changing branches and an export needed by finance.
Record whether the result uses standard configuration, a supported extension, a separate integration or manual work. A missing button may be a small interface issue; an unavailable record-level permission model may change the suitability of the whole route. Describe the consequence, not just the missing feature.
Bring the same example to a CRM development review if custom work remains justified. The question is which gap needs development, not whether a new CRM can contain a longer feature list.
Compare costs over an agreed ownership period
Choose a planning horizon appropriate to the business and make it the same for all options. Include implementation, licences or subscriptions, configuration, migration, integrations, training, support, internal administration and exit work. State how user growth or transaction volume affects the calculation.
A useful worksheet has columns for initial work, recurring external charges, recurring internal effort, uncertainty and excluded items. Keep cash expenditure separate from staff time before combining them. Do not count the same administrator both as a full internal cost and as supplier-included support.
Custom code does not eliminate recurring cost, and buying a product does not remove implementation effort. Request the basis of each line. A precise total calculated from unsupported assumptions is still a weak decision aid.
Examine portability and operational dependence
Ask how records, relationships, attachments and audit history can be exported. Test a representative export rather than accepting “CSV available” as proof that another system could use it. Identify the identifiers and permissions needed to reconstruct business context.
For a custom route, examine access to repositories, deployment accounts, documentation and recovery procedures. For a product, inspect supported APIs, configuration access, service terms and any practical switching constraints. Put contractual ownership questions to the appropriate reviewer; possession of source files alone does not resolve them.
Use a decision matrix without disguising judgement
Agree criteria before scoring suppliers. A small example might weight workflow fit at 30%, operating responsibility at 20%, total ownership cost at 20%, delivery uncertainty at 15% and portability at 15%. Those are suggested discussion weights, not a universal formula.
Score each criterion using evidence from the trial or proposal, and keep the reason beside the number. Treat a non-negotiable requirement as a gate, not something a high average can cancel out. An option that cannot enforce the required access boundary should not win because its interface scores well.
Run a limited pilot before making an irreversible commitment
Use controlled data and a representative user group to test the uncertain parts. Define the tasks, expected outcomes and time allowed for the pilot. Include at least one exception that normally requires staff intervention.
Record what the pilot did not test. A demonstration of quote approval does not establish migration quality, long-term support or every connected workflow. Keep a go/no-go decision tied to evidence, and avoid allowing pilot-specific manual work to become an undocumented operating dependency.
Write down why the selected route is justified
Keep a short decision record: the problem, options considered, evidence, unresolved conditions, accountable owner and event that would trigger a review. For the equipment supplier, that event might be expansion to more branches or the withdrawal of an essential product API.
Use custom software development where a verified gap warrants building, and retain suitable existing products around it. The in-house, agency and offshore guide addresses the separate question of who should deliver the chosen custom work.
