Buy or build: a decision you can make in an afternoon
A practical way to decide whether to pay for existing software or have something made — without a consultant, a matrix, or six weeks of evaluation.
Most buy-or-build advice is written for companies with a procurement department. Here is the version for a business where the person making the decision also answers the phone.
Start by assuming you should buy
Existing software is almost always cheaper, faster and better supported than anything anyone would build for you. Accounting, payroll, email, payments, storage, video calls: these are solved problems, solved by companies with hundreds of engineers, and you should pay them gladly.
Building only makes sense when the thing you need is specific to you. So the real question is not “build or buy”, it is: is this actually a common problem?
The three questions that decide it
1. Would your competitor’s version look the same?
If yes — buy. Invoicing looks the same in every company because tax law says it must. There is no advantage available to you in having your own.
If no — if your quoting rules, your scheduling constraints or the way you price a job are genuinely unusual — that difference is either the reason customers choose you, or a problem worth fixing. Both are cases for building.
2. Have you already tried to buy it and ended up with a workaround?
This is the strongest signal there is. Not “we looked and found nothing” — everybody finds something. The signal is that you bought something and your team invented a procedure to survive it: a naming convention, a parallel spreadsheet, a rule about which field to abuse for what.
That workaround is a specification, already written, already field-tested. It is describing exactly the software that should exist.
3. What happens if the vendor changes their mind?
Rented software can raise its price, drop the feature you depend on, or shut down. For a peripheral tool, that is an annoyance. For the thing your daily operation runs on, it is an existential risk you do not control.
The heavier your dependence, the more the argument tips toward owning it — not for ideology, but because a business should not be one pricing email away from a crisis.
The middle path most people miss
Buy or build is rarely all-or-nothing. The most cost-effective arrangement for a small business is usually:
- Buy the commodities: accounting, payroll, email, payments.
- Build the one thin layer that is specific to you — usually a single screen where your actual work happens.
- Connect them, so the specific thing feeds the commodities automatically.
That last step is where most of the value hides. You do not need to replace your accounting system; you need your job sheets to arrive in it without a person retyping them.
What building actually commits you to
Be honest about the ongoing part. Custom software needs someone to patch it, host it, and change it as the business changes. That is not enormous — for a small tool it is a modest recurring cost — but it is not zero, and anyone who tells you otherwise is selling something.
The right comparison is not “free spreadsheet versus expensive custom tool”. It is: subscription plus workaround plus the person maintaining the workaround, versus build cost spread over its life plus maintenance. Run that honestly and the answer is often less obvious than either salesperson wants it to be.
A five-minute test
Write one sentence: “Every [day/week], [person] has to [action], because [system] cannot [thing].”
If you cannot fill it in, you do not need custom software yet. If you can fill it in three times with the same system’s name, you have found your project — and probably your first version too.
Want a second opinion on which side your problem falls? Book a free call. If the answer is “buy it”, we will tell you what to buy.