Guides. Deciding what to build
How to tell whether your business actually needs custom software
Most businesses that ask this question don't need custom software. They need the tool they already pay for set up properly, or two systems talking to each other. To tell the difference, stop asking whether your software annoys people, which it always does, and run seven tests on how your company actually operates.
Each test below has a condition that decides it. Run them all before you talk to anybody, us included. None of it needs a consultant, and it's worth doing even if the answer turns out to be change nothing.
Last updated 2026-09-01
The tests
Seven questions about your operation
Count the places that claim to hold the same fact
Pick one fact your company cares about. The status of a job, what a customer agreed to, how many hours went into a project. Count how many systems hold a version of it. One system means your software is doing its job. Three that disagree is a deeper problem than reporting, because you've got three systems each convinced it's the source of truth.
The tell is the meeting where people compare screens to work out which number is right. It's a recurring cost. It never shows up on a software invoice.
It fires whenTwo or more systems hold the same fact and people check both.
Find the spreadsheet running alongside the platform
Almost every company has one. Somebody keeps a sheet beside the official tool because the tool can't hold something the business genuinely needs. A pricing calculator, a capacity plan, or the real project schedule while the platform holds a tidier fiction.
What matters is whether the business runs on it. When the workaround holds the logic that drives decisions and the paid platform holds a summary, the workaround has become the real system, and you're paying a subscription to store its output.
It fires whenA spreadsheet outside the platform holds logic the business depends on.
Count how many times one fact gets typed
Follow one job from first inquiry to paid invoice and count every point where a person retypes something that already existed somewhere else. Quote into work order. Work order into schedule. Schedule into timesheet. Timesheet into invoice. Four hops is common.
Every hop is a place where a typing error becomes an invoice dispute. The real cost is bigger. It's the reconciliation at month end that exists only because the numbers came off different keyboards.
It fires whenThe same fact is entered by a person more than twice in one workflow.
Separate what everyone does from what you do differently
Payroll, general ledger, tax filing, email, storage, and accounting are commodities. Thousands of companies do them identically, the rules come from outside your business, and buying them is obviously correct. Nobody should build their own payroll.
What's worth building, if anything is, is the part a competitor couldn't copy out of a manual. The way you scope and price the work you sell, or the way you schedule against real constraints. If a platform is making you change that to fit its model, it's charging you to become more like everyone else.
It fires whenThe process the tool fits badly is one of the few things you actually do differently.
Check which way the fitting is going
Configuration means shaping a tool around your work, which is normal and healthy. The warning sign is the reverse. The business changes how it operates to keep the software happy, on a process that worked fine before the software showed up.
Put the question to the people doing the work, and skip the people who bought the tool. What do they do that only makes sense because of the system? Every answer is a small tax. Enough of them add up to a fit problem that training won't fix.
It fires whenPeople describe steps that exist only to satisfy the software.
Count the people paying only to look
Per user pricing is fine when everyone with a seat is doing work in the tool. It gets expensive once the tool becomes where information lives, because then everyone who only needs to see something needs a seat too. Field crews, finance, a client, an executive.
When a real share of the bill is people who only read, the pricing model and your operating model have come apart. Sometimes there's a cheaper viewer tier or a shared dashboard that fixes it. Sometimes the number of people who need visibility has simply outgrown what the tool was priced on.
It fires whenA meaningful share of licensed users only ever read.
Ask what happens if the vendor changes course
Vendors reprice, repackage, deprecate features, and get acquired. So run the thought experiment. If the platform doubled its price or dropped the one capability you depend on, what would you actually do?
If the honest answer is that you'd pay whatever they asked because moving is unthinkable, you've learned which side of the relationship holds the room to negotiate. That's worth knowing before the renewal lands.
It fires whenYou'd accept almost any price increase because leaving isn't realistic.
Reading the result
What the count actually tells you
Few tests firing is the cheapest outcome you can get. Your tools fit, and whatever's irritating people is a setup or training question inside software you already own. Fix that and stop.
A middle result usually points at the joins between the tools. Two systems that both hold the truth, with a person retyping between them, is an integration problem, and connecting them is much smaller work than replacing either one.
Most tests firing at once tends to mean the way your company works and the way the platform assumes companies work have drifted apart, with people covering the gap. Every further year of configuration and workarounds and seats is money spent on a fit that won't improve. That's the case for owning the system instead of renting it.
The honest caveat
A build fixes a fit problem and nothing else
Custom software doesn't fix an undefined process, a decision nobody will make, or two departments that want different things. Software encodes those. It doesn't resolve them, and an encoded argument is worse than one left in email, because now it has a login screen.
It also doesn't remove the work of writing down how your business runs, which is the part clients underestimate. The upside is that the document is portable. It's useful whether you build, move to another platform, or stay and reconfigure.
What a build changes is ownership. A system you own has no renewal and no seat count, and nobody can deprecate a feature out from under you. That trade is on the custom software page, and the numbers behind the comparison, for the two largest incumbents, are on the implementation cost research. If a renewal is what forced the question, start with what to ask before signing it.
Questions
What people ask before deciding
How many of these tests have to fire before building is the right answer?
One or two usually means configuration. The tool can do what you need and nobody set it up that way, or there's an integration that would take the retyping out. Three or four is usually a process and integration problem worth solving before anything gets built. Once five or more fire, and especially when the commodity test and the fit test are among them, the platform has stopped being a constraint on the business and started being its shape. That's when a system you own starts to make sense.
When is custom software clearly the wrong answer?
When the process is still changing weekly, you'd be building at a moving target. It's also the wrong answer when nobody internally will own the result, when the real complaint is that people were never trained, and when the function is a regulated commodity like payroll or tax filing. And if two teams disagree about how the work should run, software won't settle the argument. It encodes whichever side wrote the specification.
Isn't this really an argument for hiring you?
It's an argument for running the tests. Most companies that contact us describe a software problem and have a configuration problem, and saying so costs us a project. If the tests above point at a fix inside the tool you already pay for, that's what you should do, and you don't need us for it.
What should we have ready before talking to anybody about a build?
One workflow written down end to end, including the exceptions people handle from memory. A list of the systems that hold the same facts. A count of the seats you pay for and who actually uses them. And an export of your current data. That's enough for anyone competent to tell you whether the answer is configuration, integration, or a build.
Run the tests, then tell us what fired
Send the list of which tests fired and one sentence on the workflow behind them. You'll get a straight answer on whether this is configuration, an integration, or a system worth owning. The first two don't need us.