Custom Software for a Small Business: Build, Buy, or Automate?

"We need a system for this" is how most custom software conversations start, and it is usually the wrong framing. The organization does not need a system. It needs a process to stop costing what it costs. There are three ways to do that, and custom software is the right one less often than people who sell custom software will tell you.

The three answers

Buy. Someone already sells software for this. Pay them, configure it, accept that it does eighty percent of what you want.

Automate what you have. The tools you already pay for can do this if someone connects them and writes the rules. No new system, no new login, no migration.

Build. Software written for your process, on infrastructure you own. Right when the process is genuinely yours, and expensive when it is not.

The decision rule

Three questions, in order.

1. Is this process part of what you sell?

If customers or clients experience the process directly (they register through it, pay through it, see their status in it), it is part of your product, and owning it has strategic value. If it is internal plumbing (approvals, reports, data moving between systems), it is not, and the cheapest reliable option wins.

2. Can a tool you already pay for do it?

Most small businesses use a small fraction of what their CRM, accounting system, and office suite can do. Before anyone proposes a build, someone should spend a day answering this question honestly. The answer is yes more often than not, and the fix is a workflow rule and an integration, not a system.

3. What is the baseline?

How many hours a week does the process cost, at what loaded hourly rate, and what do errors cost when they happen? A process that costs the organization $4,000 a year does not justify a $30,000 build. A process that costs $40,000 a year, or one whose errors cost a customer, might. The baseline method is described in its own post; it takes two weeks and it settles most build-versus-buy arguments before they start.

When buying wins

When the process is common and your version of it is not special. Payroll. Basic bookkeeping. Email marketing. A help desk. The vendor has solved edge cases you have not hit yet, and the monthly fee is cheaper than discovering them.

Buying loses when the product is priced per seat for a team that will grow, when it cannot reach your other systems without a second product, or when it forces your process into its shape rather than the other way around. That last one is subtle: staff adapt to the software, and a year later the process is worse and nobody remembers why.

When automating what you have wins

Most of the time. The common shape is: intake arrives in one tool, work happens in another, reporting happens in a third, and a person is the integration. Replacing the person with rules and connections costs weeks, not months, and nobody has to learn a new login. It also produces a baseline and a ledger, so the saving is visible.

The limit is complexity. When the rules need forty exceptions, or the tools you have cannot reach each other at all, you have found the edge of this option.

When custom wins

Three situations, reliably.

• The workflow is your product. A registration and learning platform for a training program. A client portal for an advisory firm. A grants platform an advisory practice sells to its own clients. In each case the software is how customers experience the organization, and off-the-shelf tools make every client look the same.
• Multi-tenant. What you built for yourself is worth offering to others: other counties, other chapters, other firms. Off-the-shelf tools rarely do this without becoming a reseller arrangement.
• The volume outgrew the tools. The spreadsheet has forty tabs, the workflow tool has hit its run limit, and the exceptions are now the process.

What custom should cost to run

The build fee gets all the attention. The cost that decides whether custom software was a good idea is what it costs to keep running, and who controls that cost.

• Hosting on accounts you own. The code, the database, the domain, and the cloud accounts should be in your name from day one, with whoever built it working inside them. If they are not, you do not own the software; you rent it.
• A monthly agreement, month to month. Hosting, monitoring, small changes as the process shifts, and a ledger of what the software returns. The agreement should end on short notice with a documented handover.
• New features scoped separately. A new build gets its own short scope and its own number. A monthly fee that silently absorbs unlimited change is either overpriced or underdelivered.
• The ledger. If the software saves staff time or collects revenue, you should see the figure every month. If nobody can produce it, nobody knows whether the build worked.

This is how CoBuild is structured at Civic Dialog: a fixed-fee scoping sprint, a build measured in weeks with the client's stakeholders testing each release, then, when the client wants it run rather than handed over, a monthly agreement on accounts the client owns, priced as a flat fee or, when the software is something the client sells, as a share of collected revenue. The scoping sprint is where build, buy, or automate actually gets decided, with the baseline in hand.

The ownership checklist

Whoever builds your software, ask for these in writing: the repository is in your organization's account; the cloud and database accounts are yours; credentials are held in your password manager; documentation exists that a competent engineer you have never met could follow; and the agreement states what happens to hosting and support if you stop paying. A builder who agrees to all five without hesitation is one you can work with.

If you have a process that has outgrown its tools, or a spreadsheet that has become a system, book a call. We will tell you which of the three answers it is, and the answer is often not "build."