Custom software or a subscription: how to compare them honestly

The subscription's first invoice is small and the custom build's first invoice is large, and that is where most of these decisions are made — badly. The two numbers describe different things. One is a month of access; the other is a system you keep. Comparing them without putting them on the same timeline is how a shop ends up paying for both.

Rent and purchase, not cheap and expensive

A subscription is rent. You pay while you use it, someone else fixes it, and if you stop paying you have nothing. A custom build is a purchase. You pay once, mostly, then you maintain it, and the rules inside it belong to you.

Neither is generous. Rent is expensive over a long enough period and worthless the day the vendor changes direction. A purchase is expensive up front and becomes a liability if nobody can read the code after handover. The question is not which is cheaper in general, but which of those two risks the business can carry for the next three years.

What the subscription is genuinely paying for

A subscription buys more than features:

• someone else's on-call, including the Saturday morning;
• upgrades, security patches and the accounting rules that change every year;
• a product shaped by many customers, which means the edge cases you have not met yet are already handled;
• a support address to complain to, which has real value to an owner with no technical staff;
• no dependency on a single developer who might become unavailable.

A business that ignores those is comparing a price against a price plus an unpriced obligation.

Where custom is the cheaper answer

Custom software earns its cost in situations recognisable before code is written.

• The rule that no product expresses. Pricing by wilaya, credit limits by customer history, stock reserved per contract, a discount that depends on the route and the season. Configuration covers common shapes and stops where the competitive advantage starts.
• The workaround is already the business. If the real process lives in a spreadsheet beside the packaged tool, the spreadsheet is the system, with none of the safeguards. You are maintaining custom software already; it simply has no error handling.
• Per-seat pricing decides who gets information. A price list should not be the reason a warehouse clerk cannot see stock. When access is a budget decision, the licence model is shaping the organisation.
• Two products must talk and neither vendor owns the seam. You will pay for that integration either way. The only question is who writes it and who is called when it breaks.
• The work happens offline, or on a weak signal. A counter that loses connectivity, a driver on a road with one bar, a stockroom with no network. Most hosted products assume a connection and degrade badly without one.
• Three or more people use it every day, doing the same unusual thing. At that point the time lost to the workaround is a monthly bill with no invoice.

Where the subscription is the cheaper answer

• The problem is generic. Email, payroll, accounting, file storage. These are solved, regulated, and maintained by people whose job is maintaining them. Building your own is a hobby with a payroll cost.
• The need might disappear. A seasonal line, a temporary channel, a promotion. A subscription you cancel is cheaper than code you keep.
• You need it this month. A build that arrives after the season is a build that arrived too late, however good it is.
• There is nobody to maintain it. Custom software without an owner becomes abandoned software, and abandoned software is worse than a subscription you dislike, because it fails silently.
• Switching is genuinely easy. If two vendors compete and the export is clean, the lock-in argument is weak.

The comparison, on the same timeline

Put both in the same rows and the decision becomes obvious.

	Subscription	Custom build
First payment	small	large
Ongoing payment	monthly, rises with seats and modules	hosting, maintenance, occasional work
Changing a rule	request it, wait, hope	specify it, pay for it, get it
Who fixes a bug	the vendor	whoever you can reach
When you stop paying	you lose access and the data export is whatever they offer	it keeps running until something breaks
Worst case	price rise or product retired	nobody can read the code
Time to first use	days	weeks to months

The rows that decide most cases are the ones about stopping: what happens if the vendor changes course, and if your developer disappears. Choose the failure you are better placed to survive.

The three questions worth answering first

1. Does a product already do most of this, without a workaround? Not most of the features — most of the work. A workaround that costs an hour a day is the real price of the subscription.
2. Will this work still exist in two years? If the answer is no, rent. If the workflow is how the business makes money, it will outlive several subscription price changes.
3. Who reads the code when the author is gone? If the answer is "nobody", either arrange for a second person to be able to work on it, or do not build.

Where the arithmetic goes wrong

The build estimate is usually the first release only. It rarely includes the year-two changes, hosting, backups, the certificate that expires, or the hours spent training whoever replaces the person trained.

The subscription estimate has the opposite problem. The advertised price is per user, per month, on an annual commitment, and the plan you actually need is the one above it. Add the add-ons, the onboarding fee and the currency conversion, and compare that figure instead.

Then use your own numbers, in the same window: annual cost times the years you expect to keep the workflow, against the build plus yearly upkeep plus the hours your team currently loses to the workaround. If the two totals are close, the decision is not financial. It is about who owns the rules, and that is a question for the owner rather than for a spreadsheet.

A cheap test before either commitment

Write the workflow on one page: what starts it, what it produces, who approves it, and what happens when it goes wrong. Then ask two vendors to model that page in a demo, with the exceptions included. If both can, buy the product. If both need a workaround, you have measured the gap without paying for a specification.

That page is also the first document a custom build needs, so the exercise is not wasted either way — and it usually reveals that one step exists only because of a constraint that no longer applies. Removing that step is cheaper than automating it.

Where this advice stops

It assumes the workflow is stable enough to specify. A business that reinvents its process every quarter should not commission software; it should rent until the shape settles. It assumes someone will own the system after handover — if not, the honest recommendation is a subscription, even a bad one. And it assumes the comparison window is real: three years is reasonable for a workflow that produces revenue, and far too long for a temporary channel.

We build custom software, so read the above with that in mind. We also say so when a product already fits: a system nobody needed is the most expensive kind to maintain.