We build custom software for small businesses. We also talk a lot of small businesses out of it.
Custom software is expensive, slow to deliver, and creates ongoing maintenance debt. None of those are reasons to never do it. They are reasons to know exactly when it's the right call — and the rest of the time, to be ruthless about saying no.
Here's the actual framework we use.
The three-way decision
For any operational problem, you have three options:
- Buy — a SaaS product solves it.
- Hire — a person solves it.
- Build — custom software solves it.
Most small businesses default to "buy" because it feels modern. The interesting truth: "hire" is often cheaper and better, and "build" is sometimes the only option that actually fits.
Cost a real person against the alternatives. A part-time bookkeeper at $30/hour for ten hours a week is $15,600 a year. That's roughly the lifetime cost of a $1,300/month SaaS tool plus the time of the person who manages it. The person is usually better at the work, more flexible, and doesn't have a customer success manager emailing about renewals.
That's the right frame: not "should we adopt AI / software," but "is this problem best solved by a tool, a person, or something custom?"
When to not build custom
Skip custom and buy off-the-shelf when:
- Your problem is common. Invoicing, accounting, scheduling, CRM, payroll, time tracking, project management — these have great products. Spend a weekend evaluating and commit. The custom version will cost ten times more and do less.
- The vendor is stable and the integration surface is small. If you're going to use the tool standalone, a SaaS is almost always the right answer.
- You don't yet know exactly what you need. Custom software requires that you can describe the workflow precisely. If you can't, you'll pay to learn what you need — at custom-software prices.
Skip custom and hire a person when:
- The work is judgment-heavy. Customer service that requires empathy. Sales that require relationship. Quality checks that require taste. You can automate the around-the-edges parts. The core is a person.
- The volume is low. If a problem happens ten times a week, a person handling it in five minutes is cheaper than software handling it in zero minutes. Software has fixed costs. People scale linearly with volume — which is bad at high volume and great at low volume.
- The work would change frequently. Software costs more to change than processes. If you're still figuring out how the work should be done, having a person do it lets you iterate weekly. Software locks in a guess.
When custom is actually the answer
Custom software earns its keep when all three of these are true:
1. The work is repetitive and well-defined
Custom software is good at doing the same thing many times, the same way. Customer onboarding that goes through 12 specific steps, in order, every time. A pricing model that requires lookups in three different systems. A weekly report that pulls from five sources.
If you can write out the exact steps on a single page, and those steps don't change month to month, custom can do it for you. If you can't write them out, custom can't either.
2. Existing tools don't quite fit, and the gap matters
The honest version: most custom builds are a stitching project. There's a CRM, a billing system, an inventory tracker, an internal spreadsheet, and a customer-facing form. Each of them is fine. The friction is in moving information between them.
When the cost of that friction — measured in hours per week, errors, or things that quietly fall through the cracks — exceeds the cost of building a custom layer that connects them, custom makes sense.
The phrasing test: "We have all the pieces but they don't talk to each other, and we lose [specific thing] every week as a result." That's a custom build waiting to happen.
3. You're going to use it for at least three years
Custom software is a multi-year commitment. The first version takes longer than you'd hope. The second version, six months later, is where it actually starts to pay off. By year three you've forgotten what you used before.
If you can't commit to three years — because the underlying business is changing fast, or you might sell, or the problem might evaporate when the upstream vendor releases a feature — buy or hire.
The kinds of custom builds we actually recommend
In our experience, the custom projects that work for small businesses fall into a small number of categories. Almost all of the ones that don't work are outside these.
- Internal dashboards that pull from your existing tools and show the metrics you actually care about, the way you actually want to see them. Cheap to build, instantly useful.
- Light automations that move data between two systems on a schedule, with the right handling for the edge cases. Replaces the spreadsheet that someone updates manually every Friday.
- Customer-facing portals that replace email-based back-and-forth (status updates, form submissions, document signing) with a place customers can go. Usually pays off in customer satisfaction more than time saved.
- Workflow tools for a specific operational rhythm — onboarding a new client, dispatching a job, processing a return — that no SaaS tool fits because your version is genuinely different.
The kinds of custom builds we usually talk people out of:
- Custom CRMs. Use a real one and live with the imperfections.
- Custom accounting / invoicing. A regulatory nightmare. Buy.
- Anything that's mostly a database with a form. Use Airtable, Notion, or a SaaS form tool. It's not custom-worthy.
- "AI tools" that don't have a clear non-AI version. If you couldn't describe the work as a deterministic process, the AI is going to confuse things, not solve them.
A note on AI as part of custom builds
This is where things have shifted in the last two years. Some custom workflows that were too fuzzy to build before — drafting based on context, classifying messy inputs, summarizing long documents — are now tractable because of LLMs.
That doesn't make AI a build justification. It makes it a tool inside a build. The build still needs to clear the three tests above. The AI just expands the set of problems where custom is realistic.
When we use AI inside a custom build, it's almost always sandwiched between deterministic code: structured input goes in, the LLM does the squishy middle, structured output comes out, and a human reviews the output before it touches a customer or a record of truth. That's the only way AI inside custom software is reliable enough to bet on.
The honest summary
Most small businesses don't need custom software. They need to choose three or four good off-the-shelf tools, hire one or two good people, and stop shopping.
A small fraction of small businesses have a specific operational pattern — repetitive, well-defined, currently costing real money in friction — where custom genuinely pays off. If you're in that fraction, you usually know it. The pain has a clear shape and a name.
If you're not sure which group you're in, the answer is almost always: keep buying for now, hire for the rest, and revisit the question in twelve months when you'll have more clarity. Custom built too early is more expensive than custom built late.