Every so often a small business owner tells me they need custom software. Usually they do not. Occasionally they absolutely do, and the off-the-shelf option they are being sold would be a disaster.
Here is how to tell the difference.
The default is: do not build
Custom software has costs that do not appear in the quote.
- It has to be maintained. Forever, by someone. Dependencies age, platforms change, browsers change.
- It has no community. No forum, no tutorials, no other users finding bugs before you do.
- It has one expert. If they become unavailable, you have an asset nobody understands.
- It is slower to get. Weeks or months versus signing up this afternoon.
- It will need changes. Every one is a project.
Off-the-shelf software has none of that, and someone else pays for the development. That is a large advantage and it should be beaten, not assumed away.
The bad reasons to build
"Our business is unique." Almost every business believes this and most are 90 percent standard with a few genuine differences. Build for the differences, buy for the rest.
"The software does not do it exactly how we do it." Sometimes the right answer is to change how you do it. Standard processes exist because they work, and adapting is usually cheaper than building.
"It will be cheaper than the subscription." Rarely, once maintenance is counted honestly.
"We want to own it." You own a maintenance obligation. That is a different thing from an asset.
"We might sell it to others one day." That is a decision to become a software company, which is a completely different business with different economics.
The genuinely good reasons
Nothing exists. Occasionally true, usually in a narrow trade with unusual requirements.
The gap is where your advantage is. If the thing you do differently is the actual reason customers choose you, and no tool supports it, that is worth building. Not the accounting. The differentiator.
Integration between things that will not talk. Sometimes the tools are fine and the gap between them is the problem. That is often a small, cheap build rather than a platform.
The per-seat maths has genuinely broken. At enough users, some pricing models stop making sense. Run the numbers at your projected size before assuming.
Compliance or data requirements that off-the-shelf will not meet.
The middle ground, which is usually the answer
Most of what gets called "we need custom software" is actually "we need a small amount of custom glue."
Not a platform. A specific piece that does one job:
- Pulls data from two systems and produces the thing someone builds by hand every Monday.
- Takes an inbound lead and routes, tags and follows up on it.
- Turns a form submission into a quote from your rate card.
- Watches for a condition and alerts a person.
These are small, cheap relative to a platform, and they leave your existing tools alone. They also fit exactly, because they were built around what you actually do.
That is where most of the value is in small business software work, and it is almost never what a vendor proposes, because it is not a subscription.
If you do build
- Own the code and the accounts. In the business's name, with the business's recovery email. Non-negotiable.
- Insist it is documented. What it does, how it runs, what it depends on, how to change it.
- Use boring, common technology. So somebody else can maintain it.
- Start smaller than you think. Build the one thing that hurts most, use it, then extend.
- Know the maintenance cost before you commit, and budget it as an ongoing line.
The question to ask first
Not "should we build or buy." Ask: what is the specific problem, in numbers?
How much time, how much money, how often. Then evaluate the options against that number.
A lot of proposed custom builds evaporate at that question, because the honest answer turns out to be four hours a month — which no amount of software should be spent on.