When Your Business Software Doesn't Fit

The short version

Small business software usually fails in one of three ways — it costs more every year for features nobody uses, it's built for a company ten times your size, or it's cheap and can't do the one thing your trade actually needs. Building something that fits is a short, defined process — a meeting to work out requirements, a fixed price, a deposit, then a working version with a few review sessions before it goes live. The whole point is that it does your five things properly instead of five hundred badly.

Most small businesses I sit down with are running software that doesn't fit them. Not broken software — software that was built for somebody else.

It usually shows up in one of three ways.

Too expensive

The price goes up every year and you have no leverage over it. It's charged per person, so growing costs you twice. And the feature you actually need sits one tier up, which means paying for four more you'll never open.

Add up what a handful of subscriptions costs annually and it's usually more than people expect, especially once you count the ones nobody has logged into in months.

Too big

This is the one people complain about most. The software can do five hundred things and your business needs five of them.

So new staff need training on a system where most of the screen doesn't apply to them. There's a dashboard nobody reads and a reporting module nobody has opened. Everyone has learned which fields to ignore, and that knowledge lives in their heads rather than anywhere written down.

You're not paying for capability there. You're paying for someone else's requirements.

Too basic

The opposite problem, and just as common. You found something cheap and simple, and it can't do the one thing your trade genuinely needs.

So a spreadsheet appears next to it. Somebody re-types information from one into the other. A job gets entered three times because quoting, scheduling, and invoicing don't talk to each other. Those hours are the real cost of the cheap tool, and they never appear on an invoice.

Service businesses run into this constantly with appointments — plenty of booking tools handle a calendar fine, and then can't attach the job details, the site notes, and the follow-up that make the appointment useful.

What building it instead looks like

The reason people don't consider this is that "custom software" sounds like a nine-month project with a project manager. For something scoped to five things, it isn't. Here's the actual sequence:

1. We meet and work out what it has to do. In person if you're near Princeton, Hopewell or Flemington, remote otherwise. This is the part that matters most — I want to see the spreadsheet, the workaround, the thing everyone complains about.

2. You get a fixed price and a timeline. One number, agreed before anything starts. It doesn't move unless you change what you asked for.

3. A deposit, and I start building. The rest is due on delivery.

4. You get a working version to use. Not a demo — the actual thing, with your data in it, so you find out how it feels in a real week rather than in a meeting.

5. A few sessions to fix what surfaces. Something always does. That's expected and it's part of the price, not a change order.

6. It goes live. You get the code, the credentials, and documentation written so another developer could pick it up if you ever need them to.

That's the whole engagement. No discovery phase, no account manager, no retainer you have to keep paying to keep using your own software.

What I need from you

Less than you'd think, but it isn't nothing:

  • Someone who knows how the work actually happens. Not how it's supposed to happen — how it does.
  • A couple of hours across the project for the meeting and the review sessions.
  • Honesty about the edge cases. The weird exception you handle manually is usually the thing that decides whether the software is any good.

When this is the wrong answer

If a product does what you need and the price is fair, keep it. I'd rather tell you that than sell you a project.

Building makes sense when the workarounds have started costing real hours, when you're paying for a tier to unlock one feature, or when the way you work is genuinely different from the vendor's assumptions. That's a narrower set of situations than people expect — I've written up where the line sits in more detail.

Where to start

A conversation. Tell me what the software is supposed to do and where it's failing, and I'll tell you whether it's worth building, roughly what it would cost, and how long it would take.

That costs nothing and doesn't commit you to anything. More on what I build and how projects run, and every service with how it's billed is on the pricing page.

Get in touch and I'll give you a straight answer — including when the answer is to keep what you've got.

← Back to Insights