Custom software or off-the-shelf? How a small business should decide

I build custom software for a living. So you might expect me to tell you to build something.

Most of the time, I won't.

Custom software development makes sense in a narrower set of cases than people think. Some of the most useful work I can do for a small business is to tell them they don't need me to write anything new.

Here's how I think through the decision.

Most of the time, buy it

Accounting, payroll, email, calendars, basic scheduling. These are solved problems. Thousands of companies pay for the same tools, and the vendors have spent years on the edge cases you haven't hit yet.

If you build your own version, you own every one of those edge cases. Tax rules change. Someone needs a password reset at 7am. A browser update breaks a screen. That's all your problem now.

So my default answer is boring: if a well-known product does 90% of what you need, buy it and adjust your process for the other 10%.

That's not a cop-out. Changing a process is usually cheaper than writing and maintaining code.

The option people skip: connect what you already have

A lot of "we need custom software" conversations are really about two tools that don't talk to each other.

Say you run a five-person remodeling office. Estimates live in one app. Jobs get scheduled in another. Every time an estimate is approved, someone re-types the customer's name, address, and scope into the second app.

That's not a reason to replace both tools. It's a reason to connect them.

Most modern software has an API, which is a way for one program to send data to another. Many also support webhooks, which is a program saying "something just happened" to whoever's listening. With those, a small piece of code (or a no-code tool) can move the data so nobody re-types it.

This middle option is usually cheaper than a custom build and less disruptive than switching tools. It's a big part of what I do on the automation side.

If you're not sure which tasks are even worth automating, I wrote about that in When automation is worth it for a local service business.

Signs off-the-shelf has stopped fitting

Sometimes connecting tools isn't enough. These are the signs I'd look for.

The workaround is the real process. Everyone knows the official software is "where it's supposed to go," but the actual work happens in a spreadsheet next to it.

You're paying for a lot you don't use. A big platform with a per-seat price, where your team uses two screens and ignores the rest.

The thing that makes you different doesn't fit the software. Maybe you quote jobs a specific way, and it's part of why customers pick you. If the tool forces you into its way, you're sanding off what makes you good.

People are the integration. One person knows how data moves between three systems, and when they're on vacation, things stop.

One of these on its own isn't a reason to build. A couple of them together, every week, for a long time, usually is.

What "custom" should mean for a small business

When I say custom software, I don't mean a giant platform that runs your whole company.

For a small business, it usually means one specific tool. A quoting screen that does the math your way. A simple client portal where customers check a job's status. An internal dashboard that pulls numbers from the tools you already pay for.

I'd always start with the smallest version that's useful. Build that, use it for real, then decide what's next. That's how I scope work: we agree on a specific first build before anything starts, so you know exactly what you're getting.

The mistake I'd avoid is trying to design the whole system up front. You learn more from two weeks of using a small tool than from two months of planning a big one.

The cost nobody quotes you: keeping it running

This is the part I'd push hardest on, because it's the part that gets skipped.

Software isn't a one-time purchase. Once it exists, someone has to keep it running. The tools it connects to change their APIs. Libraries need security updates. Hosting needs to be paid for and watched. Something will break quietly at some point, and someone has to notice.

I maintain software I built myself, including this site. Nothing has to go wrong for it to need attention. Keeping it running is just ongoing work.

So before you pay for any custom software development, ask:

1. Who maintains it after launch, and what does that cost?
2. Do I own the code and the accounts it runs on?
3. If the developer disappears, could someone else pick it up?

If you don't like the answers, that's a real reason to stay with off-the-shelf, even if it doesn't fit perfectly.

A quick way to decide

Here's the short version I'd use:

• Buy if a well-known product covers most of what you need and the gap is something you can live with.
• Connect if your tools are fine on their own but people are copying data between them.
• Build if the workaround has become the real process, the fit problem is about how you actually win work, and you're ready to pay for upkeep.

If you're stuck between two of these, pick the cheaper and more reversible one first. You can always build later. It's harder to un-build.

Where I come in

I'm a software engineer in the Pittsburgh area. I build websites, automations, and small custom tools for small businesses, and I write the code myself. You talk to me, not an account manager.

If you bring me a problem and the honest answer is "buy this product and change one step," I'll tell you that. If the answer is a small integration or a focused custom tool, I'll scope the smallest useful version first.

More on what I build is on the home page.

If you're trying to figure out whether to buy, connect, or build, Let's Talk About Your Project. Or book a discovery call.