How to Evaluate Build vs Buy

Who This Guide Is For

Business leaders and IT decision-makers who need new software capability and want a structured framework for deciding whether to purchase an existing product or build a custom solution.

Before You Start

• This is not a technology decision. It is a business decision that should be evaluated on fit, cost, risk, and strategic importance — not on technology preferences.
• “Buy” does not mean zero effort. Off-the-shelf products still require configuration, integration, training, and ongoing management.
• “Build” does not mean building everything. Custom builds often use existing libraries, frameworks, and services. You are building the unique parts, not reinventing the basics.

Step 1: Define Your Requirements

List what you need the software to do. Separate requirements into:

• Core requirements. The system must do these. Non-negotiable.
• Important requirements. Strongly desired. Would significantly impact the value of the system.
• Nice-to-have requirements. Useful but not essential.

Then categorise each requirement as:

• Standard. Many businesses need this. Off-the-shelf products likely handle it well.
• Non-standard. Specific to your business, industry, or workflow. Off-the-shelf products may not support it, or may require significant customisation.

If 80%+ of your requirements are standard, buying is likely the right choice. If 30%+ are non-standard, building becomes more attractive.

Step 2: Evaluate the Buy Option

Research available products and evaluate:

• Feature coverage. What percentage of your core requirements does the product meet out of the box?
• Customisation potential. Can it be configured or extended to cover the gaps? At what cost?
• Integration capabilities. Does it connect to your existing tools? Through APIs, native integrations, or middleware?
• Pricing model. Per-user, per-tier, usage-based? Calculate the five-year cost at your expected scale.
• Vendor viability. Is the vendor stable? What happens if they change pricing, discontinue the product, or get acquired?
• Data ownership. Can you export all your data? In what format? How easily?

Be wary of products that cover 70% of your needs well. The remaining 30% often requires workarounds that accumulate into significant operational friction.

Step 3: Evaluate the Build Option

Estimate the cost and feasibility of a custom build:

• Development cost and timeline. What would it cost to build the core functionality? How long would it take?
• Ongoing costs. Hosting, maintenance, support, and future development — typically 15-25% of the build cost per year.
• Team requirements. Do you need in-house developers, or will you work with an external partner?
• Competitive advantage. Does the software give you a capability that competitors cannot easily replicate?

Custom builds cost more upfront but avoid recurring per-user licensing fees and vendor dependency.

Step 4: Compare Total Cost of Ownership

Calculate the five-year total cost for both options:

Buy:

• Annual subscription fees (including user growth projections)
• Integration and customisation costs
• Training and change management
• Time spent working around limitations

Build:

• Development cost (phased over initial build)
• Hosting and infrastructure
• Ongoing maintenance and support
• New feature development

The crossover point — where custom build becomes cheaper than off-the-shelf — varies but often falls between year two and year four for mid-size deployments.

Step 5: Assess Strategic Fit

Beyond cost, consider strategic factors:

• Differentiation. Does this software create competitive advantage? If yes, owning it matters. If it is commodity functionality (email, accounting), buying is usually right.
• Control. How important is it to control the roadmap, data, and availability? Custom gives you full control. Off-the-shelf gives you the vendor’s roadmap.
• Speed to market. If you need the capability next month, buying is faster. If you need it in six months and it must fit perfectly, building is viable.
• Dependency risk. How much business risk do you accept by depending on a specific vendor? What is your contingency if they double their prices or shut down?

Common Mistakes

• Comparing only the initial cost. Off-the-shelf is cheaper to start. Custom is often cheaper to own long-term. Compare five-year totals.
• Over-customising an off-the-shelf product. If you spend as much customising a platform as you would building from scratch, you get the worst of both worlds — complexity, vendor dependency, and high cost.
• Building for vanity. “We want our own system” is not a business case. Build when the requirements genuinely demand it.
• Buying to avoid effort. Buying still requires significant effort — evaluation, configuration, integration, training, and ongoing management. It is not a shortcut.
• Not revisiting the decision. If you bought a product three years ago and your requirements have evolved significantly, the build vs buy calculation may have changed.

What Good Looks Like

The right decision results in a system that meets your requirements without excessive workarounds, fits your budget over the long term, aligns with your strategic priorities, and does not create unacceptable vendor or technical dependency. The decision is based on analysis, not assumption.

Next Steps

If you are leaning toward building, see How to Plan a Custom Software Project. If you need help evaluating specific products or custom build options, Technical Consulting provides independent analysis. See also How to Evaluate Off-the-Shelf vs Custom Software for a deeper comparison.