Build vs Buy Software: A Decision Framework With a 5-Year Cost Table

Buy software when the job is a commodity that thousands of companies do the same way: email, accounting, payroll, generic CRM, ticketing. Build software when the process is part of how you win, when no product fits without painful workarounds, or when subscription costs at your scale exceed the cost of owning a tool. In between sits the option most companies should consider first: buy the commodity core and build the custom part around it.

The question is rarely “which is cheaper this year”. Buying wins year one almost every time. The real question is which option costs less over the life of the decision, including the cost of bending your business around a tool that was built for someone else. This guide gives a framework for answering that, and a five-year cost comparison you can adapt.

Start with the question that matters

Before any spreadsheet, ask: does doing this better than competitors make us money?

• No, it is plumbing. Payroll, invoicing, email, document storage. Buy. Nobody chooses your company because your payroll software is unusual.
• Somewhat, it is how we operate. Order handling, scheduling, internal approvals. It depends on fit, scale and cost. Read on.
• Yes, it is the product or the edge. Your pricing engine, your matching logic, the customer experience your sales team sells on. Build, or at least own the part that carries the advantage.

This one question settles most cases. The rest of the framework is for the middle category.

The build vs buy decision framework

Score each factor for your situation. If most answers fall in the right column, building deserves a serious quote.

Factor	Points toward buying	Points toward building
Strategic value	Commodity process	Competitive advantage
Fit	Product covers 80%+ as is	Heavy workarounds or parallel spreadsheets
Users	Few seats	Many seats, or external customers using it
Integrations	Standard connectors exist	Several systems, custom data flows
Data control	Standard data, no special rules	Sensitive data, residency, audit needs
Speed	Needed next month	Can wait a few months for the right tool
Roadmap control	Vendor roadmap is fine	You need features on your schedule
Internal ownership	No one to own a product	An owner and budget for maintenance

A warning about “fit”. Teams often score a tool at 90% fit during the demo and discover the missing 10% contains the workflow that matters most. Test the hardest real case, not the happy path.

When buying is the right answer

Off-the-shelf software is often the smart choice, and vendors of custom development do not say that often enough.

• You need it working this month. A subscription is live in days.
• The process is standard. Accounting rules, HR processes, helpdesk flows are largely the same everywhere, and good products encode best practice.
• You lack someone to own a product. Custom software needs an owner after launch. If nobody will take that role, a vendor-managed product is safer.
• The tool has a strong ecosystem. Integrations, consultants and documentation reduce your risk.

When buying, negotiate the exit up front: data export in a usable format, notice periods on price changes, and API access on your tier.

When building pays back

Custom software earns its cost in a few recognisable situations:

• The process is your advantage. If competitors use the same tool, they get the same process. Building lets you encode what you do differently.
• You are paying for workarounds. Staff copy data between three systems, maintain shadow spreadsheets and re-key orders. That labour is a real cost, often larger than any licence.
• Per-seat pricing at scale. Subscriptions that are cheap for 10 users become a significant line at 300, every year, with annual price increases on top.
• Customers use it. A customer portal is part of your product experience. Generic tools look and behave generically.
• Integration is the product. When value comes from connecting your ERP, CRM and warehouse in a specific way, a custom layer is often simpler than chaining connectors.

What custom development costs depends on scope; market ranges are in our custom software development cost guide and, for browser-based tools, the web app development cost guide.

The hybrid: buy the core, build the edge

Most good answers are a mix. Keep the commodity system and build the part that makes you different around it, connected through APIs.

Common hybrids:

• An off-the-shelf ERP with a custom customer ordering portal on top.
• A SaaS CRM with a custom quoting tool that writes back into it.
• A standard e-commerce platform with a custom configurator or B2B pricing service.
• Internal approvals in a custom app, with documents stored in the tools people already use.

The hybrid keeps upgrades and compliance of the core on the vendor’s side, while your differentiating workflow stays yours. The key requirement is a usable API on the bought product. Check that before you sign.

A five-year total cost of ownership comparison

Illustrative example with stated assumptions: a 150-person company choosing between a mid-market SaaS tool and a custom application for an operations workflow. All figures are approximate and for structure only; replace them with your own quotes.

Cost line	Buy (SaaS)	Build (custom)
Year 1 setup	Configuration and integration: $25k	Development: $120k
Licences	150 seats × $60/month = $108k/year, +7% a year	None
Workarounds	Manual re-keying, ~0.5 FTE: $30k/year	Assumed automated
Maintenance	Included in licence	18% of build: ~$21.6k/year
Hosting	Included	~$6k/year
5-year licence total	~$621k (with yearly increases)	—
5-year total	~$796k	~$258k

In this example, building wins clearly because seat count is high and the tool does not fit, so workarounds continue. Change the assumptions and the answer flips. With 15 seats and a good fit, the SaaS five-year total drops to well under $100k, and building makes no financial sense.

That is the point of the exercise. Do not argue build vs buy in general; model your own seats, fit and workaround cost. And remember that maintenance on custom software is real. We explain what drives it in what software maintenance costs.

Risks on both sides

Risks of buying:

• Price increases you cannot negotiate once you are dependent.
• The vendor is acquired, changes direction or retires a feature you rely on.
• Data export is possible “in theory” and painful in practice.
• Your process slowly reshapes itself around the tool’s limitations.

Risks of building:

• Underestimated scope and a late launch. Reduce it with a written scope and a fixed price; see fixed price vs time and materials.
• Nobody owns the product after launch, and it decays.
• The vendor keeps the code or the accounts. Insist on your own repository and cloud accounts from day one.
• Building something a product already does well, because building is more fun.

How to run the decision in practice

1. Map the process. Write down the workflow, the users and the systems it touches. Our guide to writing a software requirements document gives an outline.
2. Trial two or three products against the hardest real case, not the vendor’s demo script.
3. Get a scoped quote for building, and for the hybrid, from a team that will tell you if buying is better.
4. Model five years with your own seats, price increases, workaround labour and maintenance.
5. Decide what you need to own — data, integrations, the customer experience — and make sure the chosen option gives you that.

If the answer is build, the next choice is who builds it: an internal hire or an outsourced team. We compare those honestly in in-house vs outsourcing. For our part, we quote custom builds as custom software development with one fixed price for a written scope, and if our estimate is wrong, the overrun is ours. If buying is the better answer for you, we will say so on the call.

The short version

• Buy commodity processes; build what makes you different.
• Test fit against your hardest real case, not the demo.
• Model five years: seats, price increases, workarounds, maintenance.
• Consider the hybrid first: bought core, custom edge, connected by API.
• Whatever you choose, own your data, accounts and exit path.

FAQ

Is it cheaper to build or buy software?

In the first year, buying is almost always cheaper. Over five years it depends on the number of users, how much you must customise the product, and how central the process is to your business. Per-seat subscriptions grow with headcount, while custom software has a large upfront cost and a steadier running cost of roughly 15–25% of the build per year.

When should a company build custom software?

Build when the process is a competitive advantage, when no product fits without heavy workarounds, when subscription costs at your scale exceed the cost of owning, or when you need control over data, integrations or roadmap. Do not build commodity functions like email, accounting or payroll.

What is the hybrid approach to build vs buy?

Buy the commodity core and build the part that makes you different around it. Typical examples are a custom customer portal on top of an off-the-shelf ERP, or a custom workflow app that uses a SaaS CRM through its API. You get speed where it does not matter and control where it does.

What are the hidden costs of buying software?

Per-seat price increases, paid tiers for features you need, integration and data-export work, consultants for configuration, and the cost of changing your process to fit the tool. Lock-in is the biggest one, because moving away later means migrating data and retraining people.

What are the hidden costs of building software?

Maintenance, hosting, security updates and the internal time needed to own a product. Custom software needs someone responsible for it after launch, either an in-house engineer or a vendor on a maintenance agreement.

How long does it take to build custom business software?

A focused internal tool or MVP often takes 8 to 16 weeks. Larger systems with several integrations take several months and are best released in stages. Buying is faster to start, but configuration and integration of enterprise tools can also take months.