Build vs buy software: a decision framework for operators

The short answer: buy commodity, build differentiators

Buy software for functions every company performs the same way: payroll, general accounting, email, basic document storage. Build when the process is how you win work or protect margin, when packaged tools force costly workarounds, or when you need to combine data from several systems in a way no vendor supports.

Most real decisions land in between, which is why the third option matters: buy the core product and build an integration or extension layer around it.

A useful question is who else would benefit from the feature. If every competitor needs it, a vendor has probably built it. If only your business has the quirk, such as a charter pricing rule, a group deposit schedule, a lease escalation formula or a custom bill of materials, packaged products rarely cover it.

Timing counts too. A subscription can be live this week, while a build takes weeks to months. If the need is urgent, buy first and replace the weak part later.

Cost comparison beyond the sticker price

Subscription pricing looks cheap per month and grows with seats, modules and add-ons. Flexera's data found 33% of SaaS spend was wasted, and Gartner estimates up to 25% of provisioned licenses go unused. Count what you pay for features nobody uses.

Building has the opposite profile: a larger upfront payment, then lower recurring fees, plus hosting, maintenance and security updates. Compare both over three to five years, and include staff time lost to workarounds on the buy side.

Do not forget exit costs. Moving off a product you have used for years means data extraction, retraining and parallel running, and the more it is customized by the vendor's consultants, the heavier that bill becomes.

• Buy: license, implementation, training, add-ons, integration fees, price increases
• Build: discovery, development, testing, hosting, maintenance, security patches, change requests

Risk: how each path fails

Buying fails through poor fit and lock-in. Data export may be limited, and a vendor can change pricing or retire a feature. Building fails through scope growth and delay. McKinsey and Oxford studied more than 5,400 large IT projects (budgets above $15 million) and found an average 45% budget overrun. A smaller project is less exposed, yet the lesson holds: keep the first release narrow and ship it quickly.

Reduce build risk with phased scope, fixed milestones and working releases. Reduce buy risk by testing a real week of your data in a trial before you sign.

Integration changes the math

Salesforce research found sales teams use an average of 10 tools, and nearly 70% of reps feel overwhelmed. Every added product creates another connection to maintain. Before buying, check what APIs, webhooks and export formats the product offers, how they are limited, and whether write access is included in your plan. Plenty of products are cheap until you need API access.

If the product connects well, buying plus a small custom integration is often the cheapest route to a fit.

Check integration direction as well. Reading data out is common; writing back is often gated behind higher plans or limited to certain objects. A requirement like creating a work order from a guest message and updating the PMS room status needs write access and webhooks, so confirm both in the documentation, not in a sales call.

A scoring checklist

Score each option from one to five against these questions, then discuss gaps instead of averaging.

Run the checklist with the people who do the work, along with with managers. Frontline staff know which workarounds exist and which features will actually be used.

• Does it fit at least 80% of the process without workarounds?
• Can you export all your data in a usable format?
• What does it cost over five years, including seats and add-ons?
• Does it connect to the systems you keep?
• Who maintains it, and how fast are fixes shipped?
• Does the process give you a competitive edge?