How to tell whether your workflow actually needs custom software

Most people who contact a developer about custom software do not need custom software. That is an awkward thing for a studio to publish, but it is true, and pretending otherwise produces expensive failures that everyone involved could have predicted.

The useful question is not "could software solve this?" Almost anything could be solved with software given unlimited time and money. The useful question is whether the specific gap between your workflow and the tools already available is large enough, and durable enough, to justify building and maintaining something new.

Here are five tests I use.

1. Can you describe the task without naming a tool?

Try to write down what actually happens, in sequence, without mentioning any software. Who initiates it. What information they need. What decision they make. Who they hand it to. What happens when something is missing.

If you can do that in a page, you understand the workflow well enough to evaluate a solution. If you cannot — if every sentence reaches for "and then we export it to..." — the process is currently defined by its tools rather than by its purpose. That is worth fixing before building anything, because a custom tool built on top of a tool-shaped process just encodes the confusion in code.

2. Is the gap in the workflow, or in the configuration?

There is a large category of problem that feels like "this software doesn't fit" but is actually "this software was never set up properly." Fields that don't exist, permissions that force workarounds, an automation nobody built, a report nobody configured.

Before commissioning a build, it's worth having someone competent spend a day in the existing tool trying to close the gap. Sometimes it closes. That day is dramatically cheaper than the alternative, and if the gap doesn't close, you now have concrete evidence of exactly where it lives — which makes the eventual build much better scoped.

3. Does the difficulty come from your specific context?

Generic software fails in specific ways for specific reasons. A tournament director tracking event profitability has genuinely unusual requirements — costs split across venues, entry fees at multiple tiers, mileage, equipment amortization, and receipts arriving over weeks. Generic accounting tools handle each piece but never assemble them into the one view the director actually needs, which is: did this event make money, and why.

That is a real case for custom software. The mismatch comes from the shape of the domain, not from anyone's failure to configure QuickBooks properly. Sport Margin exists for exactly that reason.

Contrast that with "we want a CRM but ours is annoying." The shape of a CRM is well understood by a hundred vendors. Your annoyance is real, but it is unlikely to be structural.

4. How often does the task happen, and what does it cost each time?

Multiply. A twenty-minute task done twice a week by three people costs roughly a hundred hours a year. A four-hour task done once a quarter costs sixteen. The first is a candidate for software; the second almost never is, no matter how much people complain about it — and people complain most about tasks that are painful, not tasks that are expensive.

Frequency also determines whether anyone will learn a new tool. Software used weekly gets learned. Software used quarterly gets forgotten between uses, and every session starts with confusion. That failure mode kills more internal tools than bad engineering does.

5. Who owns it after launch?

Custom software is a commitment, not a purchase. Dependencies age, platforms change, requirements shift, and the person who understood the original decisions eventually leaves. If nobody in the organization is accountable for the tool eighteen months out, you are building something that will quietly rot into a liability.

This is not an argument against building. It is an argument for building smaller — the smallest thing that changes the work, so that the maintenance surface stays proportionate to the value.

What to do with this

If a workflow passes all five tests, custom software is probably the right answer and the next question is scope, not whether. If it fails two or more, the honest recommendation is usually to fix the process, configure the existing tool properly, or accept the manual step and spend the money somewhere it matters more.

I run this evaluation as the first step of any workflow discovery engagement, and "build nothing" is a legitimate outcome. It is a much better outcome than a well-built product nobody needed.