Custom software versus off-the-shelf, and what it really costs over time

Quote someone twenty thousand dollars to build a piece of software and you can watch the reaction land. It sounds like a lot, because next to it sits a subscription that costs eighty dollars a month and works today. One number is big and one is small, so the small one wins. That’s the instinct, and it’s usually wrong, because you’re comparing a one-off price against a meter that never stops running.

The question worth asking isn’t “what does it cost to build?” It’s “what will this cost me over the five years I’m actually going to use it, and who’s holding the dial?” Once you frame it that way, the maths often goes the other direction.

The sticker price is the wrong number to stare at

Off-the-shelf software has two costs people quote and a third they don’t. The two obvious ones are the subscription and the setup. The third is what it costs every time the tool nearly does what you need but not quite.

That third cost is the one that bites. You sign up because the demo looked right. Six months in, you need a report the vendor doesn’t offer, a field they didn’t think of, or a workflow that matches how your business actually runs instead of how the software assumes it should. Now you’ve got three options, and none of them are free. Pay for the enterprise tier to get the thing turned on. Wait on a feature request that may never ship. Or change how your team works to suit the software, which is the most expensive option of the lot because nobody puts it on an invoice.

What off-the-shelf keeps charging you for

A subscription is a rental. That’s fine when the thing is genuinely generic, but a rental works in the landlord’s favour, not yours, and it pays to know how.

It’s usually per seat, so the bill grows with your team. Fifteen people at sixty dollars a month is nearly eleven thousand dollars a year, and you’ll pay it again next year whether or not the software changed. The price rises too, and not on your schedule. Vendors raise prices, retire the plan you’re on, or move a feature you depend on into a tier that costs three times as much. You don’t get a vote, because you signed their terms, not the other way round.

Right now the favourite reason for a price rise is AI. A big chunk of the software industry is cramming chat assistants, summaries and generated this-and-that into products whether customers asked for it or not, then charging more for the privilege. Sometimes it’s a flat increase. Sometimes it’s a new AI tier, or per-use credits that meter you on top of the seat you already pay for. If the feature genuinely helps you, fair enough. But a lot of it is the vendor funding their own AI bet out of your subscription, and you carry the increase whether or not you ever touch the thing.

And you can’t change it. When the tool doesn’t fit, you’re stuck waiting on a vendor whose roadmap is built for their average customer, not for you. If the process is something you do better than your competitors, bending it to fit generic software quietly files off the advantage you were trying to keep.

The worst part comes when you try to leave. The exit is often the expensive bit: years of your data living in their format, integrations wired into their system, your whole team trained on their screens. The deeper a tool sits in your operation, the more it stops being a convenience and turns into a liability, something you keep paying for partly because getting out is its own painful project. That’s the vendor lock-in problem worth weighing before you commit, not after.

Where custom software pays you back

A custom build flips the cost structure. The big number is up front, and after that the curve flattens instead of climbing.

You’re not paying per seat, so adding the sixteenth user or the fortieth doesn’t change the bill. When you need that report or that extra field, you ask for it and it gets built, on your priorities, in software that already fits how you work rather than fighting it. There’s no tier gating what you’re allowed to do, because there’s no vendor deciding it for you. And at the end of it you own an asset. The code is yours, the data is yours, and the thing keeps working for you instead of resetting to zero the month you stop paying rent.

Custom software isn’t a silver bullet, and we won’t pretend it is. You still have to host it, patch it, and pay someone to fix things when they break. The difference is what you’re maintaining. It’s yours. The code, the data and the roadmap belong to you, not to a vendor who can rewrite the deal next quarter and meter you for the privilege.

That’s the savings the upfront number hides. Twenty thousand dollars looks steep on day one. Set it against a subscription that climbs with your headcount, plus the modification tax you’ll pay the vendor every time you need it to change, and the gap closes inside a couple of years. The next section puts numbers on it.

Run the numbers over five years

Pick a process your business actually runs on and price both paths properly.

Say off-the-shelf is eleven thousand dollars a year for the team once you’re past the free tiers and the add-ons. Over five years that’s fifty-five thousand dollars, and you own nothing at the end. Now say the custom build is twenty thousand up front plus a few thousand a year for hosting, updates and the occasional change. Call it thirty-five to forty thousand over the same five years, and at the end you hold a system that fits your business and an asset you control. The custom path costs more in month one and less by year two, and the line keeps widening from there.

That’s a worked illustration, not a promise. The honest version depends on your headcount, how much the tool needs to change, and what the vendor charges to bend. But the shape holds more often than the cheap-monthly instinct suggests, and it’s the same reasoning behind why custom software costs what it does in the first place.

When buying off the shelf is still the right call

None of this means build everything. Some things you should never build, and the test is simple: is this process generic, or is it yours?

Payroll, email, accounting and the rest are solved problems. Someone has already built a better version than you ever will, and rolling your own would just be a maintenance bill you signed up for on purpose. Buy those, and don’t think twice. The same goes when the maths genuinely doesn’t clear the bar. A three-person team paying a hundred and fifty dollars a month total may never run up enough subscription cost to justify a twenty thousand dollar build, and a bespoke system built for the wrong reason is its own expensive trap.

The build case stacks up when a process is central to how you run, the off-the-shelf fit is poor, and the cost of leaving keeps climbing. Often the smartest answer is neither pure buy nor pure build but wiring up the tools you already have so they stop re-typing the same data between systems. The full decision, laid out as a test you can apply, is in our buy, build or integrate framework.

The part the cheap quote skips

The reason the small number wins so often is that it’s easy to see and the long bill isn’t. Nobody hands you a five-year invoice for the subscription, the price rises, the seats you’ll add, and the change requests you can’t yet predict. So the rental looks cheap because half its cost is in the future and out of frame.

Pull that bill into view before you sign anything. Add up what the off-the-shelf tool costs across the years you’ll actually use it, including the modifications you already know you’ll need and the leverage the vendor holds over you. Set the real total against a custom build you own and control. Sometimes buying still wins, and we’ll tell you when it does. But a lot of the time the expensive-looking option is the cheaper one, and the business that works that out is the one that added up every invoice it would sign before the contract was up, not just the first.