When Does a Small Business Actually Need Custom Software?
Custom software is usually the wrong answer and occasionally the only one. The test, what it really costs, and when building genuinely beats buying.
Somebody has told you that you need a system built. Possibly a developer, which is a bit like asking a barber whether you need a haircut.
Most businesses that think they need custom software need to configure something they already pay for, or to connect two things they already own. A minority genuinely need something built, and for that minority nothing else will do. Here is how to tell which you are before spending forty thousand dollars finding out.
Short version. Build only when the process is genuinely how you compete, no product does it, and the cost of doing it by hand is measurable in hours per week. If any of those three is missing, buy and configure instead.
The Ladder, Cheapest First
There are four rungs, and almost everybody who ends up on the fourth should have stopped on the second.
- Use what you already pay for properly. Most businesses use perhaps a third of the software they are subscribed to. The feature you want built quite often exists in a tab nobody opened.
- Buy something purpose-built. Your industry almost certainly has software written for it by people who have seen a thousand businesses like yours. It will do 85% of what you want immediately and the remaining 15% will turn out to matter less than you think.
- Connect what you have. Two systems that do not talk to each other is not a software problem, it is an integration problem, and integration is a fraction of the cost of a build.
- Build something. Only when the first three genuinely fail.
The Four Cases Where Building Is Right
1. The Process Is Your Competitive Advantage
If the way you schedule, quote or route work is why customers choose you, buying the same product your competitors use erodes the thing that makes you different. This is the strongest reason to build and the rarest.
2. Nothing Exists, Because Your Situation Is Unusual
Genuinely unusual, not "we do it slightly differently". A useful test: describe your process to somebody in the same industry. If they say "that is strange", you may be in this category. If they say "yes, same", software for it exists.
3. The Manual Work Is Measurable and Large
Somebody spends six hours a week retyping data between two systems. That is roughly 300 hours a year — at any reasonable rate, an integration pays for itself inside a year and keeps paying. This is the easiest case to justify because the arithmetic is not speculative.
4. The Per-Seat Cost Has Overtaken the Build Cost
At forty users, a $40-per-seat product is $19,200 a year. At three users it is $1,440 and building anything is madness. Scale changes the answer, and it is worth recalculating occasionally rather than assuming the decision you made at five people still holds at fifty.
The Reasons That Are Not Good Enough
- "The software we use is annoying." All software is annoying. Custom software is annoying in ways only you are paying to fix.
- "We want it to look like us." Branding an interface your staff use is not worth a build.
- "We do not want a monthly fee." Custom software has ongoing costs too — hosting, updates, security patching, the developer. They are simply less visible than a subscription line, which makes them easier to neglect and more expensive when neglected.
- "We will sell it to others later." Almost nobody does. Building a tool for yourself and building a product are different jobs with different budgets, and the first rarely becomes the second.
What It Actually Costs
The build is the smaller half. A useful rule of thumb is that the first year of ownership costs roughly what the build did, once you include hosting, fixes, the changes you did not anticipate, and the training.
The costs people forget:
- Data migration. Frequently the largest single line, and always underestimated, because real business data is messier than anybody remembers.
- Training and the productivity dip. Weeks, not days.
- Maintenance. Dependencies age whether or not you change anything. Software left alone for three years is not stable, it is unpatched.
- The bus factor. If one person understands it, you have bought a dependency as well as a system.
If You Do Build: Scope It Properly
The failure mode is not bad code. It is building the wrong thing confidently, which is why any serious supplier will want a paid discovery before quoting. A free scope is a guess, and guesses become change requests.
Insist on:
- A written scope naming what it does and explicitly what it does not. The exclusions matter more than the inclusions.
- Phases, not a big reveal. The smallest useful version first, in real use, before phase two is designed. Almost every phase-two plan changes after phase one meets reality.
- Your data, exportable, in a standard format — written into the contract.
- Documentation and a second pair of hands. Ask who else can work on this if the author is unavailable for a month.
- Ownership in writing. You should own what you paid for. See how to buy agency work for the contract questions that matter.
The Honest Recommendation
Spend a week seriously trying to solve it with what you have. Ask your current vendor whether it does the thing — the answer is yes more often than anyone expects. Get a quote for an integration before you get one for a build.
If you still need it built after that, you probably genuinely do, and you will now be able to explain exactly why, which makes the scope far better. That is how our own software work starts: a paid discovery that quite often ends with us telling somebody not to build anything.
Common Questions
When Should a Small Business Build Custom Software?
When three things are true at once: the process is genuinely how you compete, no existing product does it, and the manual cost is measurable in hours per week. If any one of those is missing, configuring an existing product or integrating two you already own will be dramatically cheaper and usually better.
How Much Does Custom Software Cost for a Small Business?
The build is roughly half the first-year cost. A reasonable rule of thumb is that year one of ownership costs about what the build did once you include data migration, training and the productivity dip, hosting, and the changes nobody anticipated. Data migration is the most commonly underestimated line.
Is Custom Software Cheaper Than Paying Subscriptions?
It depends entirely on seat count. At three users a $40-per-seat product is $1,440 a year and building is madness; at forty users it is $19,200 and the arithmetic changes. Custom software also has ongoing costs — hosting, patching, developer time — which are less visible than a subscription line and therefore easier to neglect.
What Is the Biggest Risk When Commissioning Custom Software?
Building the wrong thing confidently. It is why a serious supplier charges for discovery before quoting — a free scope is a guess and guesses become change requests. Insist on phases rather than a single reveal, and get the smallest useful version into real use before phase two is designed.
What Should Be in a Custom Software Contract?
A written scope naming what it does and explicitly what it does not, ownership of what you paid for, your data exportable in a standard format, documentation, and an answer to who else can work on it if the original developer is unavailable. The exclusions matter more than the inclusions.
