Is custom software always more expensive than buying a tool?

No, but it's almost always more expensive up front. The comparison that matters is the total over about three years, so the build and its upkeep against the subscription, the seats you'll add, and the work people still do by hand because the tool doesn't quite fit. I'd do that maths before anything else, because it settles a lot of these decisions by itself.

We already pay for a tool that nearly does what we need. Should we replace it or extend it?

In most cases extend it, and only extend the part that's really yours. Replacing a mature tool means rebuilding the boring parts it already does well, and you're paying for that without getting anything back. The exception is when the gap sits in the middle of how you make money, because then the workarounds aren't just annoying, they're what it's costing you.

How do I know whether our process is a real advantage or just a habit?

Ask why it's the way it is. If the answer is that someone set it up like that years ago, it's a habit and you should bend it to the tool. If the answer is that it's why customers choose you, or why your margin is better than the firm down the road, it's an advantage, and bending it would cost you the thing you're trying to protect.

What happens if the person who built our system leaves?

I think this is the biggest risk with custom software, and it's worth asking about directly. What protects you is documentation your own team can work from, ordinary technology and nothing exotic, and a proper handover so you're not left depending on the person who built it. If you get a vague answer when you ask about that, I'd take it as a no.

Can we start with an off-the-shelf tool and build something custom later?

Yes, and it's often the sensible order. Running on a bought tool for a year teaches you what your process needs, which is far cheaper than finding out halfway through a build. Before you commit, check you can export your data in a usable form, because that's what makes the move possible later.

How long does a custom build take compared to buying?

Buying takes days or weeks. Building takes weeks or months, depending on how much of the business it touches. If you've got a hard date driven by something outside your control, that difference usually decides it on its own, and I'd rather scope the build to fit the date than miss it.

All guides

Should we buy software off the shelf or have something built for us?

Custom software vs off-the-shelf: how to tell which one you actually need

Most comparisons like this are written by someone who sells one of the two options, and this one is too. So read the section on buying as the part I've got the least reason to write well, and judge the rest with that in mind.

The first thing on my won't-do list is selling you a platform when a smaller fix would solve it. I don't say that to sound modest. I think it's the most common way this decision goes wrong, and it's expensive in a way that takes a long time to show up.

Start by assuming you should buy

I think off-the-shelf should be the default, and it should take real evidence to move you off it. Someone else has already built the thing, tested it against thousands of businesses, and is paying a team to keep it working while you think about something else. You can be using it next week, and if it turns out to be wrong, you just stop paying for it.

Custom software has none of that going for it. It doesn't exist until it's built, it's been tested against one business, and somebody has to own it afterwards. So it's only worth paying for when what you get back outweighs all of that.

When off-the-shelf wins

Common problem. Accounts, payroll, email, helpdesk, booking, file storage, e-signatures. If thousands of businesses have the same problem, thousands of businesses have already funded the solution, and building your own version of something that's already solved is about the clearest waste of money there is.

Mature tool. It's got an export function, an API, a support line and years of edge cases somebody else already found. A lot of what you're paying for is the years of bugs already fixed, and that's worth more than anything on the marketing page.

A process you can adapt. This is the one people resist, and it's usually the right move. Most processes are the way they are because someone set them up that way once, not because they're better. If you can't explain why yours is different beyond history, bend it to the tool and take the saving.

A roadmap you don't maintain. Rules change, integrations break and platforms deprecate their APIs. With a bought tool, someone else deals with that.

A fixed date. If you need it working next week and the date's fixed by something outside your control, that often settles it.

A lower three-year total. Do the maths properly and it often is lower. That means subscription plus seats against build plus upkeep, over a realistic period, which is longer than the first year. If the subscription comes out cheaper, buy it.

When custom is worth it

Your process makes the money. If the way you do the work is why customers choose you, bending it to fit a tool gives away the thing that makes you different.

Paying per seat for a fraction of a tool. Ten people on a platform where each of them uses one screen is a bill that grows with headcount and gives you nothing extra when it does.

Several systems that need to agree. Each one might be excellent on its own. The expensive part is the person who copies between them every morning, and that person never shows up in the cost of the tools.

The gap is where your margin is. A tool that handles ninety per cent of the work but misses the part that makes you money doesn't really solve the problem.

Guarantees about your own data. You won't find that as a setting in any tool. The Lead Data Platform case study shows what it takes.

Tools that nearly fit

The worst outcome, worse than buying wrong or building wrong, is a tool that almost works, which you then customise eighty per cent of the way towards what you needed.

You end up paying the licence and carrying the complexity. Those customisations are the first thing to break at upgrade time, and the vendor's under no obligation to care. Meanwhile the missing twenty per cent gets handled by a spreadsheet, a shared inbox and someone's memory, and that ends up being the real system, with nobody looking after it.

If a tool nearly fits, work out which twenty per cent is missing. If it's administrative, live with it and stop shopping. If it's the part the business is built on, stop customising and build that part properly.

Four questions

Should you build it?

No email required, and it will tell you to buy something if that is the answer.

Is this process how you make money, or the admin around it?

Is there already a tool that does most of this?

Could you change how you work to fit a tool?

Who has to use it?

0 of 4 answered.

Often it's both

Most real answers aren't one or the other. Buy the ordinary parts and build the bit that's actually yours, then connect them.

A review platform I built sits on Airtable. The database, the hosting and the uptime came with it, and none of that was worth building. What I built on top was the relational model, custom intake forms, role-specific interfaces and the assignment logic. Those were the parts specific to that business, and they were the reason its spreadsheets had failed.

That comes up a lot. There's a bought platform underneath, a purpose-built layer where the business really is different, and a connection between them that keeps working without anyone copying data by hand. I think it's the right answer most of the time, and you don't hear it much because it doesn't suit either side to say it.

The costs people forget

On the buying side, per-seat pricing compounds as you grow and customisation breaks at upgrade time. And if you can't get your data out in a usable form, you usually only find out when you try to leave.

On the building side, software needs maintenance whether or not anyone budgeted for it, and somebody internally has to own it. If only one person understands it, you're dependent on them, so insist on documentation your team can work from.

A way to decide

Write the process down, and mark each step as either "this is how everyone does it" or "this is why we are better". If almost everything falls in the first column, buy and adapt. If the second column's short but it's where the money is, buy the rest and build that part. And if the second column is most of the page, it's probably a build.

Questions people ask

Is custom software always more expensive than buying a tool?: No, but it's almost always more expensive up front. The comparison that matters is the total over about three years, so the build and its upkeep against the subscription, the seats you'll add, and the work people still do by hand because the tool doesn't quite fit. I'd do that maths before anything else, because it settles a lot of these decisions by itself.
We already pay for a tool that nearly does what we need. Should we replace it or extend it?: In most cases extend it, and only extend the part that's really yours. Replacing a mature tool means rebuilding the boring parts it already does well, and you're paying for that without getting anything back. The exception is when the gap sits in the middle of how you make money, because then the workarounds aren't just annoying, they're what it's costing you.
How do I know whether our process is a real advantage or just a habit?: Ask why it's the way it is. If the answer is that someone set it up like that years ago, it's a habit and you should bend it to the tool. If the answer is that it's why customers choose you, or why your margin is better than the firm down the road, it's an advantage, and bending it would cost you the thing you're trying to protect.
What happens if the person who built our system leaves?: I think this is the biggest risk with custom software, and it's worth asking about directly. What protects you is documentation your own team can work from, ordinary technology and nothing exotic, and a proper handover so you're not left depending on the person who built it. If you get a vague answer when you ask about that, I'd take it as a no.
Can we start with an off-the-shelf tool and build something custom later?: Yes, and it's often the sensible order. Running on a bought tool for a year teaches you what your process needs, which is far cheaper than finding out halfway through a build. Before you commit, check you can export your data in a usable form, because that's what makes the move possible later.
How long does a custom build take compared to buying?: Buying takes days or weeks. Building takes weeks or months, depending on how much of the business it touches. If you've got a hard date driven by something outside your control, that difference usually decides it on its own, and I'd rather scope the build to fit the date than miss it.

Where this came from

This guide is written from real work rather than from research. These are the engagements it draws on.

Lead Data PlatformOutbound Marketing Agency Review HubMedia Business

If this left you with a question it did not answer, that is worth an email rather than another page of reading.

Start a project