Build vs Buy for Small Business Software

We build custom software, and we start most conversations by trying to talk people out of it. Buying is usually cheaper and faster, with less risk. When somebody who should have bought a product gets sold a custom project, it ends badly for everyone.

Here’s the test we use.

Start by assuming you should buy

For most business functions, somebody has built the product, spread the cost across thousands of customers, and spent years finding edge cases you haven’t thought of. Buy accounting, payroll, CRM, email, and scheduling for common trades. The case for building any of those is close to nonexistent.

The advantages of buying are large and easy to underrate. The product exists today and somebody else maintains it. It improves without you paying for each change, and if it turns out wrong you can leave.

The question that decides it

Evaluate the best-fitting product honestly, then ask: to use this, what would we have to change about how we work, and does that change make us worse?

Most of the time the answer is "a few things, and no." Your process grew the way it did partly by accident. Adopting the product’s way is fine, and often an upgrade.

Once in a while the answer is "a central thing, and yes." The product can’t handle the process your customers choose you for. It might be scheduling logic that lets you turn work around faster, a pricing model nobody else offers, or the quality step your reputation rests on. Flattening that to fit the software trades your advantage for a licence fee.

Build when your process is what customers are paying for.

The other legitimate build cases

Nothing exists for your niche

Software vendors skip very narrow industries because the market is too small. Tire mold machining, specialty lumber grading and regional franchise service networks are examples. Sometimes no product exists for them at all.

The integration is the job

You have four systems that won’t talk to each other. The work is the connective tissue between them, with no new application needed. That’s custom by definition, and it’s often much smaller than a full build.

The licence arithmetic flips

Per-seat pricing at forty users for ten years adds up to a large number. Run that arithmetic against a build plus maintenance, and include the maintenance, which people tend to leave out.

The costs people forget on each side

The right-hand column explains why buying wins so often. A build commits you to ongoing costs for as long as you run it, so compare it against the full total.

The hybrid, which is usually where people land

Most businesses that need something custom need one custom piece. Buy accounting and payroll. Build the one thing that’s yours, and connect it to the rest.

Nearly every project we take on looks like that. Thomson’s Landscaping got a point-of-sale system built around their process, connected to the inventory system they already had, and they kept their accounting package. The scope was smaller and so was the risk, and the custom work went where it paid off.

Before you decide

1. Write down the process as it runs day to day, which may differ from what the org chart says.
2. Find the three best-fitting products and get demos using your real scenario.
3. For each, list what you’d have to change, and mark the changes that make you worse.
4. If that list is empty or trivial, buy. Today.
5. If one item is central and makes you worse, scope a build around that one item.

The scoping quiz runs a version of this in seven questions and hands back a written brief. Sometimes the brief says you should buy something.