Buy, Subscribe or Build: A Three-Question Test for SME Software

You are paying every month for software your team half-uses, and somebody has just quoted you for a custom system that costs more than a delivery van. The sales call says subscribe. The developer says build. Neither of them has to run your business on the result.

Buy, subscribe or build is a decision most owners make on the first-year price, which is the part that ages worst. Three questions settle it better. Here they are, worked through for a delivery business with twelve riders, a shape we see often.

Buy, subscribe or build: three options, not two

These are three different commitments, not three prices for the same thing.

• Buy. Pay once for a packaged product and configure it. Still common for accounting packages and point-of-sale tills. Cheap across five years, but you carry the upgrades, and the day the vendor stops updating it becomes your problem.

• Subscribe. A monthly fee per person. No server, no engineer, always current, and you can stop. You are renting someone else's rules: their pricing, their roadmap, their decision to retire the feature you depend on.

• Build. Custom software that fits your process exactly and costs nothing extra per person. You pay up front, and then you own it: the hosting, the bugs, and the call at six in the morning.

Most owners compare year one across the three and stop there. Year one is the least informative of the three years.

The three questions

Ask them in this order. The first decides most cases on its own.

1. Is this how you compete, or just how you operate?

Payroll, accounting, e-mail, file storage: how you operate. Every company in your sector does it roughly the same way, and no customer has ever chosen you because of it. Subscribe, take the default settings, move on.

Dispatch rules, pricing logic, the way you handle a failed delivery: how you compete. If you do it better than the company down the road, that difference is worth owning.

The test we use: if a competitor copied this part of your operation exactly, would you lose anything? If the honest answer is no, do not build it.

2. How many workarounds does the ready-made option need?

You cannot answer this from a demo. Demos run on the vendor's data, driven by the vendor's best operator. Run a real week on a trial instead, with your own staff, and count the places where somebody keeps a parallel spreadsheet, retypes a number, or has to remember something the software does not track.

Our rule of thumb: up to three small workarounds, subscribe anyway, because nothing fits perfectly. More than that, or a single workaround that touches money, and the fit is wrong however good the demo was.

The workarounds that bite hardest in our market are predictable: mobile money reconciliation, cash on delivery, customers whose address is a landmark rather than a street, and prices negotiated per customer. Tools built elsewhere assume none of these.

3. What is the three-year number, including the work?

Compare three years, not twelve months, and put your own quotes in. The numbers below are placeholders to show the shape of the sum.

• Subscription: seats times price times 36 months, plus the annual increase, plus what it costs to get your data out and into your other systems. Fifteen people at ten dollars a month is five thousand four hundred dollars over three years, before any increase.

• Build: the quote, plus hosting, plus maintenance — we budget fifteen to twenty per cent of the build cost a year — plus your own hours specifying and testing it. A twenty-thousand-dollar build lands nearer thirty thousand across three years, and four times the year-one cash of the subscription.

• Buy: the licence, plus the upgrade you will eventually be forced into, plus somebody's time keeping it alive.

The crossover is usually headcount. Five people rarely justify a build. Fifty often do, because the subscription line grows with the team and the build does not.

Worked through: a delivery business with twelve riders

Twelve riders, three people in the office, a few hundred deliveries a day across two cities. Half the customers pay cash on delivery, half by mobile money. The owner asked us to quote one system to run all of it.

The useful move was to stop treating it as one decision. Split the operation into parts and answer the three questions for each part separately.

• Accounting and payroll — subscribe. How they operate, not how they compete. The ready-made options fit with one small workaround, and the three-year number is a rounding error next to a build.

• Dispatch and the rider app — build. This is the part customers feel: who gets which drop, in what order, and what the office can promise on the phone. The off-the-shelf dispatch tools they trialled assumed street addresses and card payment, and both workarounds touched money.

• End-of-shift reconciliation — build, and build it first. Two screens: what each rider was given, what they brought back, and what the mobile money statement says. This is where money actually leaks, and no general tool does it the way a cash-heavy operation needs.

• Customer notifications — buy the pipes. Nobody should build SMS or WhatsApp delivery. Pay a provider for sending, and build only the rules that decide when a message goes out.

What they commissioned in the end was one custom build noticeably smaller than the system they first asked us to price, plus two subscriptions and a messaging provider. The build got cheaper because it stopped trying to be an accounting package.

Build the part your customers would notice if it stopped. Rent the rest.

Most answers are a mix, and sometimes the answer is not yet

A mix is the normal outcome, and it has its own cost: the seams. Decide up front where a customer record lives, which system is the source of truth for an order, and how data moves between them. Two systems that both believe they own the customer will cost you more than either one did.

Sometimes the answer is that it is too early. If your process has changed twice this quarter, or you have run this line of business for less than six months, software will freeze a process you have not settled. Run it on a shared sheet for another quarter and automate one painful step instead — matching a mobile money statement against yesterday's orders and flagging only the mismatches, for example. A small automation over tools you already pay for often removes the reason for the large purchase.

Five signals you are about to choose wrong

• You have only seen the demo. Ask for a trial your own staff run for a week on real orders. A vendor who refuses is telling you something.

• The build quote has no line for after launch. Hosting, monitoring, backups and fixes do not stop at handover. A quote without them is not cheaper, it is incomplete.

• You are building around a feature you would use twice a year. Write down how often you actually need it before it justifies a custom system.

• You are paying per seat for people who log in monthly. Ask for a read-only or lighter tier. Most vendors have one and few advertise it.

• Nobody can say where the data lives or how to get it out. Ask for a full export before you sign, and open the file. It is a cheap test that tells you exactly how hard leaving will be.

What to do next

1. Write your operation on one page and split it into parts: money, operations, customers, admin. You are making one decision per part, not one decision.

2. Answer question one for each part. Anything that is how you operate goes straight to a shortlist of two subscriptions.

3. Run a real week on that shortlist with your own staff. Count the workarounds and mark the ones that touch money.

4. Whatever is left is your build candidate, and it will be smaller than what you started with. Get it quoted, with the after-launch line included.

5. Put the three-year numbers side by side, add your own hours, and decide.

If you want a second opinion before you sign or commission anything, talk to us. We build the custom part for companies shaped like this one, and we will say so when the honest answer is a subscription and a quiet afternoon with a spreadsheet.