Is custom software still expensive for a small business?

Far less than it used to be. The work that made custom software cost six figures was mostly hand-writing plumbing that is now generated or bought off the shelf. What is left is the part that was always the real work: deciding what should exist. That is why a system that would have been a big-company purchase a few years ago is now a normal small-business one.

Build Custom Software or Buy Off-the-Shelf? How to Actually Decide

Q: What are the pros and cons of building custom software versus buying off-the-shelf SaaS?

Off-the-shelf is fast, cheap to start, and maintained by someone else, but you adapt to it, you pay per seat as you grow, and the part it does not do has no setting and no workaround you can export. Custom fits your workflow exactly and stops charging you for growing, but it takes weeks rather than minutes to start, and somebody has to own it afterwards.

Q: When should a small business build custom software instead of using off-the-shelf tools?

When the workflow you would be automating is the thing that actually makes you money, when your software bill grows every time you hire, or when you are paying for three or more tools that each do part of one job and do not talk to each other. If none of those is true, buying is the correct answer and building is an expensive way to feel productive.

Q: How do I know if my business has outgrown Airtable and Zapier?

Three signals. You are hitting record limits or task caps and paying to raise them. Someone on your team is the designated person who knows how the automations work, and things break when they are away. And when an automation fails quietly, you find out from a customer rather than from an alert. That combination means the glue has become the product.

Q: How do service businesses cut software costs without losing functionality?

Start by listing every tool with its monthly cost and the one job it does. Most stacks have two or three tools doing overlapping work and one doing something genuinely irreplaceable. Cancel the overlaps first, that is free. Only then consider whether the remaining spend, plus the hours lost moving data between them, would be better spent owning one system instead.

Every owner I work with hits this question eventually, usually around the point where the software bill stops feeling like a rounding error. Someone suggests building something custom. Someone else says that sounds expensive and risky. Both of them are right, in different situations, and the argument usually goes nowhere because nobody has defined what they are actually comparing.

So let me lay out the whole thing the way I would if we were sitting in your office.

What you are actually choosing between

The phrase “build vs buy” makes it sound like two doors. In practice there are five routes, and most owners only get pitched two of them:

Vertical SaaS — software built for your specific trade. Jobber, Housecall Pro, ServiceTitan, and their equivalents in every industry.
The no-code stack — Airtable or Notion for the data, Zapier or Make for the automation, Softr or similar for the interface. You assemble it yourself out of rented parts.
App builders — Bubble, Glide, and friends. One platform, real custom logic, visual editor.
A dev shop or freelancer — bespoke software built to your spec, hourly or by project.
Productized custom — a custom system with the scope, price, and go-live date fixed before anything starts.

Routes 1 through 3 rent you capability. Routes 4 and 5 build it. That is the actual distinction, and it matters more than the label.

What are the pros and cons of building custom software versus buying off-the-shelf SaaS?

Buying is fast, cheap to start, and somebody else’s problem to maintain. You are live this afternoon. The vendor employs people who think about nothing but that software. When it breaks, it is their weekend, not yours. For most jobs, most of the time, this is simply correct and I will tell you so.

The costs show up later, and they show up in three specific places.

You adapt to the tool. Every off-the-shelf product encodes assumptions about how a business like yours works. Where those assumptions match, you get years of value for very little money. Where they do not, you get a workaround — a spreadsheet beside the system, a naming convention everybody has to remember, a step where someone re-types something that already exists elsewhere. Workarounds are invisible on the invoice and expensive in practice.

Per-seat pricing is a tax on growth. Your software bill rises every time you hire. That is fine at five people and it is a real line item at twenty-five. Notice what it does to the incentive: the tool gets more expensive precisely as you succeed, which is exactly backwards from how a good input should behave.

The missing 20% has no exit. This is the one owners underestimate. When a tool does not do something, there is usually no setting for it, no add-on, and — critically — no export that would let you do it somewhere else. The report you want does not exist and the data needed to build it yourself is not available in a usable shape. You are not blocked by a feature gap. You are blocked by a data gap, and those do not resolve with a support ticket.

Building inverts all three. The system matches how you actually work, the price stops tracking headcount, and the data is yours in a form you can query. In exchange you take on two things you did not have before: a project, and something to own afterwards.

The project part is the one people fear and it is genuinely the smaller risk now. The part worth thinking hard about is ownership. Custom software is not a purchase, it is a small ongoing responsibility — someone has to host it, patch it, and change it when the business changes. Any honest answer to “should I build” includes a plan for who does that.

When should a small business build custom software instead of using off-the-shelf tools?

Here is the test I actually use. Three questions, and you want a clear yes on at least one.

Is the workflow you would automate the thing that makes you money? Not payroll. Not bookkeeping. The specific sequence your business runs on — how a lead becomes a scheduled job becomes an invoice becomes a repeat customer. If your edge lives in that sequence, then bending it to fit generic software is filing down the thing that makes you different. If your edge is elsewhere, buy the standard tool and get on with it.

Does your software bill grow every time you grow? Count what you pay per seat, per record, per contact, per automation run. If that number scales with your success rather than with the value you get, you are renting on terms that get worse over time.

Are you paying three or more tools to each do part of one job? Not three tools doing three different jobs — that is normal and fine. Three tools doing one job, with someone moving data between them. That is the pattern where custom pays, because you are already paying for the integration; you are just paying for it in hours instead of dollars.

If all three are no, you do not need custom software. You might need to use what you have properly, which is cheaper and less exciting.

How do I know if my business has outgrown Airtable and Zapier?

I have a lot of affection for this stack. It is the fastest way to find out what your process actually is, and I would rather someone prototype in Airtable than spend three months writing a spec for something nobody has tested.

You have outgrown it when three things are true at once.

You are paying to raise limits. Record caps, task caps, seat counts. When you are upgrading tiers to keep the same workflow running, the pricing model has stopped matching your usage.

One person is the designated knower. There is somebody who understands how the automations fit together, and when they are on holiday, changes wait. That is not a personnel problem, it is an architecture problem — the system’s logic lives in a place that cannot be read by anyone else.

Failures are silent. This is the real one. Zapier will email you when an automation errors. The failure that hurts is the one that does not error — a record arrives in a slightly different shape, does not match the filter, and is quietly skipped. Nothing is broken, so nothing tells you. You find out from a customer three weeks later, and by then it has happened forty more times.

That third signal is the line. Once the connective tissue between your tools has become load-bearing, it needs to be something somebody owns and can test, and no amount of additional Zaps gets you there.

How do service businesses cut software costs without losing functionality?

Before you consider building anything, do this. It takes an afternoon and it is free.

List every tool you pay for, its monthly cost, and the one job it does. Write the job in a short sentence — if it takes two sentences, the tool is doing two jobs and that is worth knowing.

Almost every stack I have seen has the same shape: two or three tools with overlapping functionality that arrived at different times for different reasons, and one or two doing something genuinely irreplaceable. Cancel the overlaps first. That is free money and it requires no project.

Then add a second column: roughly how many hours a month does your team spend moving information between these tools, or re-entering something that already exists somewhere else? You do not need a precise number. You need to know whether it is closer to two hours or twenty.

Now you have the real comparison. Not “custom software versus my SaaS bill,” but “custom software versus my SaaS bill plus the hours.” That second number is usually the larger one and it is the one nobody puts on a spreadsheet.

What about the hybrid nobody pitches?

The framing that gets sold is all-or-nothing: keep your tools, or replace everything. The version that actually works most often is neither.

Keep the tools that genuinely fit. Your accounting software is fine. Your email is fine. Build custom only for the part that is yours — the workflow, the data model, the interface your team lives in all day — and let it talk to the rest.

This is usually the right first step, and it is a smaller decision than it sounds. You are not betting the business on a rebuild. You are building the one piece nobody sells, and connecting it to the pieces plenty of people sell well.

How I would decide if it were my business

Honestly? I would start by not building anything.

I would do the tool inventory. I would cancel the overlaps. I would find out whether the pain is a tooling problem or a process problem, because a surprising amount of what looks like bad software is actually an undecided process, and building custom software around an undecided process just makes the confusion permanent and expensive.

Then, if the three questions above still came back yes — the workflow is the business, the bill scales with growth, several tools are doing one job — I would build. Not everything. The one piece that is actually mine, with a fixed scope and a date, and a clear answer to who owns it afterwards.

And if it came back no, I would use the tools I have properly and spend the money on something that grows revenue instead. That answer is less interesting and it is right more often than the other one.

The question is never really “build or buy.” It is “where does this cost land, and who carries it.” Once you can answer that, the decision usually makes itself.