Start from the assumption that you should buy, not build. That is not modesty. Off-the-shelf software has had thousands of users find its bugs, somebody else paid for the development, it is supported by a team whose whole job is that product, and it can be running on Monday morning.
Custom software is slower and costs more up front. It only makes sense when the fit is the problem. So the real question is not "which is better". It is "how much is the gap between how this tool works and how we work actually costing us?"
That is measurable. Here is how to measure it.
The workaround test
Step one. Pick the person who spends the most time in the tool. Give them a sheet of paper for five working days.
Step two. Every time they do something the software should have done for them, they write one line and a rough number of minutes. Round to five minutes; precision is not the point. The things you are counting are:
- Typing the same information into a second system
- Exporting to a spreadsheet to answer a question the tool cannot answer
- A manual check that exists because the tool gets something wrong
- A message to a colleague to fill a gap the software leaves
- Anything at all involving the phrase "you have to remember to"
Step three. Add up the week. Multiply by the number of weeks you actually work in a year -- forty-something for most businesses. That is your annual hours lost to the gap.
Step four. Price those hours at what that person costs you, not at minimum wage: salary plus employer costs, divided by their working hours. If two or three people all do the workaround, count all of them.
Step five. Compare that annual figure with what a build would cost, remembering that a build is a one-off with a smaller ongoing cost, while the workaround repeats every year for as long as you keep the tool.
Our rule of thumb: if the lost hours do not clear the build cost within about a year to eighteen months, do not build. Keep the tool. Live with the workaround, or find a better product.
That rule will tell most businesses to stay where they are, and that is the correct answer most of the time.
What the test misses
The tally only catches things that look like work. Three costs never show up on it, and they can flip the decision.
Mistakes that reach a customer. A double booking, a wrong price on an invoice, a missed appointment. You are not counting the minutes; you are counting the customer.
Work you do not do because it is painful. Nobody logs the report they stopped producing, or the follow-up calls that quietly stopped happening because the list was awkward to pull.
One person holding it together. If the workaround only functions because a particular member of staff remembers the rules, you have a business risk, not a software preference.
Be careful with these, because they can be used to justify anything. Write them down explicitly, in words, before you decide. "We double-book roughly once a month and it costs us a room and an apology" is a real argument. "It feels inefficient" is not.
The comparison, plainly
| Off the shelf | Custom | |
|---|---|---|
| Up-front cost | Low, often nothing to start | The whole build, paid over the project |
| Ongoing cost | Per user per month, grows as you hire | Hosting and maintenance, roughly flat |
| Time until it is running | Days | Weeks to a few months |
| Fit | Close, with a gap you work around | Shaped to how you actually work |
| Who fixes a bug | The vendor, on their timetable | You decide the priority and pay for it |
| New features | Whatever they build for everyone | Whatever you ask for, and nothing else |
| Main risk | Price rises, product changes direction, company is sold | Overruns, and knowledge sitting with one supplier |
| Best when | Your process is normal for your trade | Your process is part of why customers choose you |
The middle option most people skip
Most businesses do not need to choose. They need to keep the product they have and build the missing piece.
A connection between two systems so the same order stops being typed twice. A small tool that does the one thing the product cannot, sitting beside it. A report that pulls from three places into one screen.
This is usually the cheapest good answer, and it is the one nobody sells hard, because it is a smaller job. Ask for it specifically.
Four questions that decide it faster
Is the thing you do differently the thing customers pay you for? A firm with a genuinely unusual way of quoting has a reason to build; that method is the business. A firm with an unusual way of filing invoices does not.
Has anyone properly tried three alternatives? "We looked at it" is not trying. A fortnight of real use with real data by the person who will live in it is trying. Products change fast, and the one that was wrong three years ago may fit now.
Can the product already do it, if somebody learned how? Configurable software is often blamed for problems that are really training problems. Building custom software to solve a training problem is a very expensive way to avoid a two-day course.
What happens if you do nothing for a year? If the honest answer is "we cope", you have your decision, and you can revisit it when the answer changes.
Where custom genuinely wins
When your process is unusual and that is the point. Engineering firms with their own pricing logic, schools with their own admissions flow, operators running something nobody has written a product for. That is the ground custom software is for.
When you are paying per seat for a lot of light users. Twenty people who each open the system twice a week can cost more in licences than a build, and the arithmetic gets worse every time you hire.
When several systems need to meet in one place and no product covers all of them.
When you intend to sell the thing later. An internal tool your customers keep asking to buy is a different project entirely -- see SaaS platforms -- and it needs accounts, billing and customer separation built in from the start.
What we would say to you
If you describe your problem and an existing product would solve it, we will tell you which one and send you away. That is not generosity; a client who builds something they did not need is not a client who comes back.
The decision is arithmetic you can do without a software company. Count the workaround. Price it. If it does not clear the cost of the fix, the answer is no, and you have saved yourself a project.
Filed under
- buying software
- custom software
- cost
- decision