How to decide when off-the-shelf software stops working
By Steele Consulting
Every business that’s been running for more than a few years has a tool that doesn’t quite work anymore. The CRM that fits 80% of your sales process. The accounting system that handles every transaction except the one type that actually matters to your margins. The inventory tool that needs three integrations and a spreadsheet to give you the report your operations team actually uses.
You haven’t replaced it because replacing it is expensive and the current tool mostly works. You haven’t extended it because it isn’t quite broken enough. You’ve quietly accepted that this is just how things are.
This is the build/buy/bend crossroads, and most businesses sit at it longer than they should.
In our 24 years building custom software at Steele Consulting, we’ve watched this exact decision come up dozens of times. The mistake we see most often isn’t choosing wrong between the three options — it’s failing to recognize that there are three options at all. Bending an off-the-shelf tool to fit your business isn’t free, and it isn’t temporary. It’s a quiet, ongoing tax most businesses pay for years before they think to question it.
This post lays out the three options honestly, the five variables that decide between them, and a scorecard you can run on your own situation in about ten minutes.
Why most businesses bend for too long
The default response when an off-the-shelf tool stops fitting is to keep using it. Build a workaround. Add a plugin. Hire a consultant to configure it. Bolt on a spreadsheet. Run a manual report once a week. Each individual workaround is small. The cumulative cost rarely is.
There’s a specific reason this happens. Each decision to bend looks rational on its own — a few hours of work, a small plugin cost, a one-time integration. Nobody ever sits down and decides “we’ll spend $400K a year working around our CRM.” It accumulates one workaround at a time, until somebody calculates the total and the number is startling.
In the DRIFT framework from our post on tech debt, we call this version of the cost a Friction Cost — the cumulative tax of working around bad systems instead of with them. Bend is the most common source of Friction Cost we see in growing businesses, and the hardest to surface, because none of the individual workarounds were wrong.
The three options, honestly
Option 1: Buy
Use the off-the-shelf tool as it ships. Configure within its limits. Accept its workflow.
When it works: the tool fits 90% or more of what you need, the gaps are tolerable, and your business isn’t differentiated by the process the tool handles. Buy is the right answer more often than software vendors will tell you. Accounting, payroll, basic CRM, standard project management — most businesses do not need custom software for these.
When it fails: you’re contorting the business to fit the tool. You’re hiring people whose job is to operate a workaround. The workflow that should be your competitive advantage is being shaped by what the tool can do, not what your business needs.
Option 2: Bend
Extend the off-the-shelf tool with integrations, custom configurations, plugins, automations, or a partial custom layer that talks to the existing platform.
When it works: the tool is doing most of the work well, and the gap is bounded — one or two specific integrations, a custom report, a workflow extension. The cost of bending is genuinely lower than the cost of replacing. The thing you’re bending around is unlikely to change much.
When it fails: the bends accumulate. Each one made sense at the time. None of them get retired when they should. The system becomes a small custom build wearing an off-the-shelf skin, and you’re paying both bills.
Option 3: Build
Replace the off-the-shelf tool — wholly or partially — with custom software designed around your business.
When it works: the workflow is genuinely specific to your business, the tool is a meaningful competitive lever, and the cost of bending is now higher than the cost of building. The data you depend on is locked inside a system you can’t extract from cleanly. The need is going to exist for years.
When it fails: you build because building feels strategic, when bending or buying would have done the job. Custom software has a long tail of maintenance, security, and evolution costs. Every line of code you own is a line of code you’re responsible for forever. Building should be a decision you make because the alternative is worse, not because the alternative is boring.
The five variables that decide
When clients ask us which option is right, five variables almost always settle it. None of them on its own is decisive. Together, they’re usually unambiguous.
Variable 1: Uniqueness
How much of this workflow is unique to your business versus standard across your industry?
If 90% of the workflow is industry-standard, buy. If 50% is industry-standard and 50% is yours, bend. If the workflow is fundamentally how your business is different from competitors, build.
Variable 2: Workaround cost
How much are the current workarounds costing you per month — in people-hours, error rates, customer impact, and missed reporting?
Be honest about this. Most teams have been doing the workaround so long they don’t see it anymore. Count the hours.
Variable 3: Lifespan
How long will this need exist?
A six-month need is almost always wrong to build for. A permanent, core-to-the-business need that’s going to evolve over the next decade is almost always wrong to keep contorting.
Variable 4: Customer-facing impact
Is this process something your customers experience directly, or purely internal?
Customer-facing processes have higher stakes — a clunky workaround your team has accepted is a problem your customers shouldn’t have to. Internal-only processes can tolerate more imperfection.
Variable 5: Strategic differentiation
Is this process a commodity, or is it part of how you compete?
If competing on this process means a faster, smoother, smarter version of the workflow, custom software earns its keep. If the process is the same as every competitor’s, you don’t gain advantage from owning the code.
The Build Score
Score each variable from 1 to 5, where 1 leans toward Buy and 5 leans toward Build. Add the five numbers.
- 5–12 → Buy. The tool fits, or there’s a better tool to buy. Stop bending.
- 13–19 → Bend. Extend the current tool intelligently, with a sunset plan and a budget for the workarounds.
- 20–25 → Build. Custom software earns its keep here. Choose your partner carefully.
The score isn’t an oracle. It’s a forcing function. If your score lands in the gray zone between two bands, the real conversation is which variable is dragging the score — and whether you trust that answer.
We’ve turned this into a one-page scorecard our clients use ahead of any major software decision. If you’d like a copy, reach out and we’ll send it over.
Common patterns that fail
A handful of patterns are worth flagging directly, because they show up over and over:
- Bending past the point of reason. Every workaround was a small, rational decision. The sum of them costs more than a rebuild would have, two years ago.
- Building when buying would have done. Custom software for a workflow that isn’t competitively differentiating. You’ll spend the next decade maintaining code you could have rented for a few hundred dollars a month.
- Buying without a real fit assessment. The tool covers 90% of your needs in the demo and 50% of them in production. Six months later you’re bending it heavily anyway.
- Building part of a system and bending the rest, with no integration plan. Two halves of a process held together by manual handoffs and weekly emails. The most expensive version of all three options at once.
- Treating “build vs buy” as a one-time decision. It isn’t. Most businesses revisit it every two to three years as the business evolves. The right answer this year is not necessarily the right answer next year.
How this connects to the other decisions you’re making
Build, buy, or bend rarely lives alone either. The score that says Build typically lands you in the same conversation we covered in What to Look for in a Software Partner When You’re Not Technical Yourself — because building is only as good as the people you build with. The score that says Bend usually means a Friction Cost is quietly compounding inside your DRIFT picture, and the question becomes whether to absorb it or eliminate it. Read together, these pieces are the playbook for any business sitting at this crossroads.
How we approach this at Steele Consulting
We’ve helped clients through every version of this decision — including, regularly, telling them that the right answer is to keep buying or to bend smarter, not to build with us. Greg Steele has a line he uses in early conversations: “If you can dream it, we can build it.” The line we don’t say out loud as often, but mean just as much: not everything is worth building.
When the score says build, we build. When the score says bend, we’ll often help architect the bend so it doesn’t compound — a smarter integration, a cleaner extension, a sunset plan for the workarounds. When the score says buy, we’ll tell you, and we’ll point you toward what we think the right buy actually is.
If you’re sitting in the middle of this decision and want a second set of eyes — or you’d like the one-page Build Score scorecard sent to you — reach out and we’ll walk through it.