Start with off-the-shelf as the default
If a generic tool covers 80% of what's needed, that's usually the right starting point — not because custom software is bad, but because generic tools are cheaper, faster to deploy, and someone else maintains them. Custom software only wins when the remaining 20% is the part that actually matters to the business, and bending a generic tool to cover it costs more in workarounds than building the real thing would have cost outright.
The real signal isn't cost, it's fit
The instinct is to compare sticker prices — a SaaS subscription against a development quote. That's the wrong comparison. The real question is how much the business is bending around the software's limitations versus the software bending around the business's actual process. A generic tool that requires three manual workarounds and a spreadsheet on the side isn't actually cheaper than custom software; the cost just moved from a line item to lost staff time, which is harder to see and easier to ignore.
Signs off-the-shelf is genuinely enough
- The workflow is standard enough that other businesses in the same space use the same tool successfully.
- The team doesn't need deep customization, just configuration.
- Speed to launch matters more than exact fit right now.
- The budget doesn't support ongoing maintenance of a custom system yet.
Signs custom software is worth it
- The process is genuinely specific to the business, not just "we do it differently for no real reason."
- Multiple disconnected tools are being stitched together manually to cover one workflow.
- The workaround cost (staff time, errors, delays) is already larger than a development budget would be.
- The software itself is meant to be a competitive advantage, not just internal plumbing.
The middle ground gets missed
It's rarely a binary choice. A common, underused pattern is keeping a generic tool for the parts it handles well — accounting, generic CRM, off-the-shelf auth — and building custom software only for the specific process that doesn't fit anywhere else, then connecting the two. That's usually cheaper and lower-risk than a full custom rebuild, and it avoids reinventing solved problems just because one part of the workflow doesn't fit.
What this looked like for a real project
CHBTK is a useful example of the "process is genuinely specific" case. Community coordination across a large resident base, spread across Facebook groups, WhatsApp, and word of mouth, isn't a workflow any generic community platform handles well out of the box — the actual requirement was bringing scattered information into one system built around how that specific community already organized itself, which is what made custom software the right call rather than forcing an existing platform to fit.
The practical takeaway
Don't start a custom software conversation by asking what to build. Start by asking whether an existing tool already solves this for other businesses, and if not, whether the reason is a real difference in how the business operates or just inertia. That answer determines whether custom software is a smart investment or an expensive way to reinvent something that already exists.