Short answer. Buy when a ready-made tool covers most of your process and your needs are common. Build when the software is part of how you compete, when tools do not fit your workflow, or when the cost of workarounds and licences exceeds the cost of owning the code.
- Buy for common needs, build for what sets you apart
- Compare cost over several years, not the first invoice
- Plan for data, integrations and being found
Start by leaning towards buying
If a product already does what you need, buying is usually faster, cheaper at the start and carried by a team whose whole job is that product. Accounting, email, payroll and scheduling are good examples. Thousands of businesses have the same need, and the tools reflect that.
So the first question is not "can we build this?" It is "what would we have to give up if we bought it?" Write down the five things the process must do. Try two or three products against that list, using real tasks rather than a sales demo. If one covers four or five, buy it.
Buying also lowers a risk that people forget: a custom system needs someone to maintain it. If you do not have a plan for that, a hosted product is safer.
When building makes sense
Building starts to look sensible in a few situations.
The software is how you compete. If your booking flow, pricing logic or customer portal is part of why people choose you, a generic tool limits you to what every competitor can also do.
Your process does not fit. You are bending the business around the tool, or running spreadsheets alongside it to fill the gaps. Those workarounds are a cost.
You need systems to talk to each other. Connecting a CRM, payments, calendars and a website is often where off-the-shelf options fall short, or charge heavily for connectors.
You need control of the data. Some businesses need records kept in particular places, or under particular rules. Owning the system makes that simpler.
Licences grow with you. Per-seat pricing that is fair for five staff can be painful for fifty.
Count the cost over time
The first invoice misleads in both directions. A subscription looks cheap and renews every month. A custom build looks expensive and then you own it.
Compare over three to five years. For buying, add the licences, the add-ons, the time staff spend on workarounds and the cost of switching later. For building, add the build, hosting, fixes, updates and the people who will look after it.
Include less obvious items too. Can you export your data if you leave? Who owns the code you paid for? How much of your process depends on one vendor's decisions about pricing and features?
Also count search. Software that customers use publicly, such as a booking page or a directory, needs to be found. Pages built without structure, speed or crawlable content can be invisible. That is easier to plan into a build than to repair later.
The middle path
It is not always one or the other. A common approach is to buy the common parts and build only the piece that is yours. You might keep an off-the-shelf accounting system and build the customer portal that sits in front of it, joined by an integration.
Another is to start with a product to learn how your process really works, then build once the requirements are clear. Money spent on a short first version tends to teach more than months of planning.
Whichever way you lean, write down what success looks like before you start, and decide who will own the result.
If you are weighing it up, we can look at the options with you. Book a strategy call, or run the free AEO check if the question is really about being found.