Most small businesses that ask us to build custom software should not build custom software. This article is the filter we apply before quoting — written out so you can apply it yourself, for free, before anyone sends you a proposal.
There is an obvious conflict of interest in a development firm publishing a guide about when not to hire a development firm. We publish it anyway for a practical reason: the projects that go badly are almost always projects that should never have started, and they cost us more in reputation than they earn in fees. Filtering early is in our interest as much as yours.
So here is the honest sequence. Work through it in order.
Gate One: Have You Genuinely Tried the Products?
“We looked at a few and they did not fit” is not the same as evaluating. Nearly every business believes its process is unusual. Most are wrong, and discovering that costs nothing.
A real evaluation means: two or three products, actual trial accounts, your real data, and a specific person tasked with making each one work for two weeks. At the end you should be able to write down — concretely — where each one failed.
Then examine your list of failures and sort them honestly:
- Cosmetic. “The layout is ugly,” “it uses different terminology than we do.” These are not reasons to build. They are reasons to adapt.
- Process preference. “It makes us approve before sending; we do it the other way.” Ask whether your way is actually better or merely familiar. Usually it is familiar.
- Structural. “It assumes one customer per job; we bill three parties per job at different rates.” Now you have something. This is a genuine mismatch between the product's model of the world and yours.
If you have not yet mapped which processes are even worth the exercise, the automation diagnostic ranks candidates before you shop. Only structural mismatches justify building. If your list contains none, buy the closest product and change your process to match it. That sentence has saved businesses more money than anything else we tell them.
Gate Two: Is the Process Actually Settled?
Software makes a process permanent. If three people do the job three different ways, custom software will encode whichever way the loudest person described during requirements, and the other two will resent it into disuse.
The test is uncomfortable but quick: ask three people who perform the process to write down the steps independently. If the three descriptions disagree materially, you do not have a software problem yet. You have an agreement problem, and it costs nothing but a meeting to fix.
This is the single most common reason custom projects disappoint, and it is entirely preventable before a dollar is spent.
Gate Three: Will Someone Own It?
Every custom system needs a named internal owner — someone who notices when it breaks, knows what it was supposed to do, and decides what changes next. Not a committee. A person.
Without that person, the following happens with grim reliability: the system runs fine for months, something upstream changes, it silently stops doing part of its job, and nobody notices for a quarter. Then the system is declared unreliable and abandoned, and the money is gone.
If you cannot name the person today, you are not ready. That is not a scheduling problem to solve during the project; it is a precondition.
Gate Four: Does the Arithmetic Work?
You do not need a sophisticated model. You need two honest numbers.
First: hours currently consumed. How many hours per week does this process take across everyone involved, including the re-keying, the chasing, and the fixing of errors? Measure it for one week rather than estimating it, because estimates in this category are wrong by large factors in both directions.
Second: what portion is genuinely removable. Not all of it. Software eliminates data movement and enforcement; it does not eliminate judgment, exceptions, or customer conversations. Assume you remove a meaningful fraction of the mechanical portion, not the whole process.
Multiply the removable hours by a fully-loaded labor cost and compare against a build cost plus ongoing maintenance. Then apply the correction that most proposals omit: custom software has a running cost. Hosting, updates, occasional fixes, and the internal owner's attention. Budget for it annually rather than pretending the project ends at launch.
If the payback is not clear within a couple of years on conservative assumptions, the honest answer is usually no — or not yet.
The Exception the Arithmetic Misses
The hours-saved calculation is the right frame for internal operations. It is the wrong frame for the other reason small businesses build software: the software is part of what you sell.
A customer portal that wins contracts your competitors cannot serve. A pricing tool that lets you quote in a day when the industry takes a week. A system that lets you take on a category of work you currently turn away. In those cases the question is not “how many hours does this save” but “what revenue does this make possible, and how confident am I.”
Be rigorous here, because this is also where wishful thinking lives. “Customers will love it” is not evidence. A specific customer saying “we would move our volume to you if you could do X” is evidence. Get the evidence before you build.
If You Pass All Four Gates
Then build — and build the smallest useful version first.
The instinct is to describe everything you want and ask for a price. Resist it. Choose the single workflow that hurts most, and scope only that. You will learn more from one thing running in production than from six months of specification.
Real people using it for real work, in production. This tests the firm, the assumption, and your own organization's willingness to change — at a cost you can absorb if the answer is no. Any firm unwilling to work this way is telling you something.
Source code, repository, and cloud accounts in your name from day one. Not transferred at the end — yours from the start. This single decision determines whether you are building an asset or renting a dependency.
Extend the parts people actually used. Kill the parts they routed around. The willingness to cut planned scope after seeing real usage is what separates projects that deliver from projects that merely finish.
What It Costs, Without False Precision
Any article giving you a confident dollar figure for “custom software” is guessing, because scope varies by more than an order of magnitude. What is useful is knowing what moves the number:
- Integration surface. How many existing systems must it talk to, and do they have documented APIs? This drives cost more than feature count.
- Data migration. Bringing history along is frequently more work than the new functionality.
- Compliance requirements. Regulated data changes the architecture, not just the paperwork.
- Number of distinct user types. Each role is effectively another interface to design and test.
- How settled your process is. Which is why gate two exists.
Ask any firm for the smallest first phase and its price, rather than a total. Firms that can only quote the whole thing have not thought about your risk.
Where WorkflowUnity Fits — Plainly
We are a US-based custom software firm building on AWS. Code and cloud accounts are yours from the start, we work in small paid phases, and we would rather lose a project at the gate than deliver one that should not have been built.
Choosing between kinds of outside help is its own decision — see our small business automation consultant guide. If your evaluation turned up only cosmetic complaints, if three people describe the process three ways, or if you cannot name an internal owner — we are not the right call yet, and we will tell you on the first conversation. Those are all fixable internally, at no cost, and fixing them is worth more to you than anything we could build this quarter.
Frequently Asked Questions
When should a small business build custom software?
Only after four conditions hold: you have genuinely trialed two or three products and found a structural mismatch rather than cosmetic complaints; the process is settled enough that three people describe it the same way; a named individual will own the system; and the arithmetic works on conservative assumptions including ongoing running costs. If any one of these fails, the honest answer is to buy a product or wait.
How much does custom software cost for a small business?
Scope varies by more than an order of magnitude, so any confident single figure is a guess. What drives cost is the integration surface (how many systems it must connect to and whether they have documented APIs), data migration, compliance requirements, and the number of distinct user roles. Rather than asking for a total, ask each firm to price the smallest first phase that delivers real value — that number is meaningful and comparable.
Is custom software cheaper than SaaS subscriptions over time?
Sometimes, but the comparison is often made unfairly. Custom software is not a one-time cost — it carries hosting, maintenance, occasional fixes, and the attention of an internal owner. When people compare a build price against annual subscriptions and conclude custom wins, they have usually omitted the running cost entirely. Include it, use conservative savings assumptions, and see whether payback still arrives within a couple of years.
What is the most common reason custom software projects fail?
Building on an unsettled process. If people perform the work inconsistently, the software encodes one version and the others route around it. The second most common reason is the absence of a named internal owner — systems without one break quietly, go unnoticed, and get declared unreliable. Both causes are visible before the project starts and both are free to fix.
Should I build custom software to win new business rather than save time?
That can be a stronger case than internal efficiency, but it demands harder evidence. “Customers would love this” is not evidence. A specific customer stating they would move volume to you if you could do a specific thing is evidence. Get that before building, not after — revenue-driven builds fail most often because the demand was assumed rather than confirmed.
Who should own the code for custom software?
You should, from day one rather than at handover — the source code, the repository, and the cloud accounts the system runs in. If any essential part lives in the development firm's account or depends on a proprietary framework only they maintain, you have a dependency rather than an asset, and your switching cost is effectively unlimited. Settle this in the contract before work begins.