Most software decisions in a small or mid-sized business get made once, under time pressure, by whoever needed the tool. Then they’re never revisited. Not because anyone decided not to, but because there’s no moment in the calendar when someone asks whether the thing you picked four years ago is still the right thing.
That absence is expensive, and the cost is invisible in a specific way that makes it hard to argue about. It does not appear as a line item. It appears as everyone being slightly slower forever.
The three costs that never show up in the comparison
When a business evaluates software, it compares subscription prices, maybe implementation fees. Three larger costs are almost always omitted.
The integration you will do twice. Getting your data into a system, connecting it to what you already run, reshaping a process around it. This is frequently larger than the license, and you will pay a version of it again when you eventually switch. Nobody budgets for the second one.
The change you won’t be allowed to make. This is the one I care about most. Write down the change you would want to make to this capability in two years: a different pricing model, a new customer type, a workflow that doesn’t exist yet. Then ask whether the product would let you. If the answer is “we would file a feature request,” you’re not buying a tool, you are buying a ceiling. You will hit it at the exact moment your business is doing something interesting enough to be worth doing.
The translation tax. If your process doesn’t match the tool’s model, somebody is doing manual work every week to bridge the gap. A spreadsheet alongside the system. A step that exists only because the software won’t accept the real sequence. That work is permanent, it grows with volume, and no one tracks it because each instance is small.
The workarounds are your audit
If you want to know how well your technology actually fits, don’t survey anyone. Go find the spreadsheets.
Every parallel spreadsheet, manual reconciliation, and exception process is a precise, detailed bug report about which requirement your systems missed. Nobody maintains a shadow system for enjoyment. They do it because the official path does not work and they still have a job to do.
I’ve found this exercise more informative than any formal review, in businesses of every size. It takes an afternoon of asking people what they do outside the system, framed as curiosity rather than compliance, and it produces a ranked list of your actual problems in the order they cost you.
The framing matters. If people think they are being audited, the spreadsheets disappear and you learn nothing. If people think you’re trying to make their week easier, they will show you things you didn’t know existed.
Buy versus build, with the line in a useful place
The standard advice is to buy everything and never build. I think that is now slightly out of date at the small end, and I want to be careful about why.
Buy anything that’s a solved problem with a stable definition. Accounting, payroll, payments, email, storage, authentication. Your version would be worse and nobody chooses you for those.
Build only where your specific answer is the reason customers pick you, or where the translation tax is high and permanent.
What changed is the cost of the second category. For a certain kind of internal application, mostly forms, a database, permissions, and scheduled jobs, a mature framework now handles nearly all of it, and the build is a weekend rather than a quarter. I did this myself: I replaced a commercial CRM with one I wrote, not because the commercial one was bad but because my work is relationships rather than deals, and every product in the category is built around a pipeline moving toward a close. I was doing manual translation work every week.
The advantage wasn’t what I added. It was what I could leave out. No forecasting, no territory management, no quota tracking. Removing those made the tool faster to use every day, permanently. A commercial product can’t do that for you, because it has to serve the forty-person sales team as well as you.
I would still tell a business with a standard process to buy. The point is that “always buy” has become “buy unless the misfit is structural,” and structural misfit is more common in owner-operated businesses than the software market admits.
A review that takes one meeting a year
Put a single recurring item on the calendar. For each significant system, three questions.
What are people still doing by hand around this? That is your fit measure.
What did we want to change this year and could not? That’s your ceiling measure.
If we were choosing today, would we choose this? Not to trigger a switch, but because saying “no, but switching is not worth it” out loud is a real decision, and it’s different from never having asked.
Most of the time the answer is to keep what you have. That’s fine. The value isn’t in switching, it’s in knowing what the current choice costs you, so that when the cost eventually exceeds the switching cost, you notice at the time rather than three years later.
Be the first to comment