Business Growth Systems
The Workaround-Cost Test is a decision framework for choosing between configuring an off-the-shelf CRM or ERP platform and commissioning a custom build, resolved by comparing two real costs: what it costs, ongoing, to bend a standard platform into shape with workarounds, against what a custom system would actually cost to build and maintain. It exists because almost any process can technically be forced into almost any platform with enough manual steps and stitched-together integrations — the question is never whether that's possible, but whether its accumulated cost is honestly higher than building the right tool. Applied correctly, it turns a build-versus-buy decision usually made on gut feeling into an itemized cost comparison.
Use this test when a business is choosing new CRM or ERP software, is frustrated with manual workarounds in its current platform, or is being pitched a fully custom system by a vendor with an obvious incentive to sell one. It's most useful before signing a contract or starting a build, not after — the highest-value use is preventing a business from either overpaying for unnecessary custom software or quietly accumulating years of workaround costs in a platform that was never going to fit. It's not needed for a genuinely simple, standard process — the test itself takes time, and a straightforward operation with no unusual handoffs rarely needs it.
Step 1 · Map the real process first
The actual process is documented as it really happens — how leads genuinely arrive, how a deal genuinely moves stage to stage, where a handoff between people or systems genuinely occurs today — rather than the official version of the process, because those two versions are often different in exactly the places that matter. A sales team might have a process diagram showing leads flowing straight from a web form into the CRM, while in reality a large share arrive by phone or messaging apps and get manually re-typed in by whoever picks up, a step the diagram never mentioned. The mistake this step prevents is scoping a platform or a custom build against a process that isn't the one actually happening, which guarantees the resulting system misses real requirements from day one.
Step 2 · List every required workaround
Every point where a standard platform would need to be bent to fit the real process gets listed explicitly, along with the ongoing cost of each one — a manual spreadsheet kept alongside the CRM, an automation chain stitching two tools together, a recurring double-entry step — because these costs are individually small but compound over months and years of daily use. A business whose CRM can't natively handle its multi-stage approval process might build a workaround of tagging records and manually checking a shared spreadsheet for status, a workaround that costs only minutes a day per staff member but adds up to a real labor cost once totaled across a year and multiple people. The mistake this step prevents is judging a platform as good enough based on subscription price alone while ignoring the real, ongoing labor cost of every workaround required to make it function.
Step 3 · Weigh that against a custom build's real cost
The total ongoing cost of the workarounds identified in the previous step is compared honestly against what a custom system would cost — not just to build, but to host, maintain, and update over the same time horizon — because a custom system is only the right call when the accumulated workaround cost genuinely exceeds it. A business losing significant staff time each week to manual workarounds, projected over two or three years, may comfortably exceed what a scoped custom module would cost to build and maintain, while a business only losing an hour a week to minor friction almost never clears that bar. The mistake this step prevents is commissioning custom software because it feels more bespoke or professional, when the actual workaround cost never justified the price and maintenance burden of a custom build.
Step 4 · Decide gap by gap, not all-or-nothing
The decision is made gap by gap — identifying the specific point or two where the standard platform genuinely fails and building or integrating a targeted solution just for those — rather than treating it as one binary choice between a fully off-the-shelf platform and a fully custom system replacing it outright. A business might keep its standard CRM for contact management and pipeline tracking but commission a small custom module purely for an industry-specific compliance workflow the CRM can't handle, instead of replacing the entire CRM with something custom. The mistake this step prevents is over-scoping a custom build to replace an entire platform when the itemized gap analysis only ever justified fixing one or two specific pieces of it.