Custom Software vs Off the Shelf: When to Patch, Buy, or Build

A manual step, inserted because two systems don't talk to each other. A spreadsheet bridging the gap between what the CRM tracks and what the team actually needs. A process that works, but only because one person knows exactly where to click and in what order.

Every business accumulates these. These aren't signs of failure. They're signs of a business that kept moving when things weren't perfect, which is almost always the right instinct in the moment.

The problem isn't that workarounds exist. It's that they tend to quietly shift from temporary fixes into permanent infrastructure. And once that happens, the business starts adapting to its own patches rather than the other way around.

If you've followed along from Workflow Mapping for Small Businesses and A Lighter Approach to Process Documentation, you've already built the foundation: you can see how work actually moves through the business, you've captured it in a format that stays current, and you've got a sense of how you'd want it to work instead. The question now is what to do with the gap between those two, specifically, when a workaround is fine to leave in place and when it's telling you something needs to change.

How workarounds accumulate

Workarounds rarely arrive as conscious decisions. They emerge from a reasonable response to a constraint: a tool doesn't do quite what you need, a process doesn't account for an edge case, or a handoff between teams has a gap that someone fills manually.

In the moment, the patch makes sense. It's faster than redesigning the process. It costs nothing to implement. And it works.

The accumulation happens because each workaround is small enough to seem insignificant on its own. Nobody raises a flag over an extra copy-paste step or a quick check in a separate spreadsheet. These things just become part of how the work gets done. Over months and years, a business can end up carrying dozens of these small compensations, each one rational in isolation, but collectively creating a web of dependencies that nobody fully sees.

This is normal. Every business that has grown beyond its initial setup carries this kind of accumulated adaptation.

When patching becomes structural

There's a meaningful difference between a workaround that compensates for a known limitation and one that has become load-bearing. A temporary patch is something the team is aware of and could describe as a compromise. A structural one is something the team has stopped noticing. It's just how the work gets done now.

A few signals that patching has moved from temporary to structural:

When you onboard someone new, listen to how you explain the awkward steps. The tell isn't a blank "that's just how we do it." People always have a reason. It's a confident "we do this because the CRM can't tag it," or "because the two systems don't talk." The explanation is true, which is exactly why nobody questions it. But every one of those becauses is naming a limitation, and a limitation is the kind of thing a tool, an automation, or a bit of consolidation can often remove.

The same work is spread across tools that don't agree with each other. Part of the team lives in the CRM, part in a spreadsheet, and the email client quietly does a lot of the heavy lifting in between. When the same information is being hand-carried between systems, that's not a small patch anymore: it's the shape of the business.

And once the same information lives in more than one place, someone has to keep it in sync. You update one system, then go update the other to match, maybe a third. Nothing is broken, but every change now costs two or three times what it should, and the team is carrying the mental overhead of remembering where everything has to line up. That's the point where a patch has turned into permanent busy work.

Work that pulls you out of your flow to log it somewhere else. You finish something, then you have to stop and go re-describe it in a separate system (hop into email, hop into a project tool), re-stating work you just did so there's a record of it. The cost isn't the few minutes of typing, it's breaking focus to do it, over and over. And when the doing and the logging live in two different places, there are usually ways to connect them so the record keeps itself.

Removing it feels risky even though it was never meant to be permanent. When people are reluctant to change something that was supposed to be temporary, it's usually because other things now depend on it in ways nobody fully understands.

None of these are emergencies. But they're signals that the systems have started setting the terms.

Buying before you check the fit

Not every patch is something you back into. Sometimes it's something you buy. A tool gets adopted (a platform, an analytics suite, an AI product) because it's genuinely impressive and it genuinely might help. The trouble isn't the wanting to invest, which is the right instinct. It's that the tool gets chosen before anyone checks it against how the work actually happens, so the fit gets discovered after the purchase instead of before. It's the same failure as the rest of this article, in reverse: the business adapts to the tool instead of the tool fitting the business.

The step that got skipped is the evaluation, the same question every redesign should start with: what's the actual friction here, and does this thing address it? And the catch is that the evaluation can't come from the person selling you the tool. A sales engineer's job is to say "yes, we can do that." They'll say it in good faith, and they may even be right, but their bias only runs one direction. If that demo is your evaluation, you don't have one.

The honest answer isn't to go find someone neutral, because there's no such thing. Anyone who knows these systems well enough to judge them has opinions and scar tissue. Some people swear by a given platform, some can't stand it, and the same is true of nearly every tool worth arguing about. What you're actually choosing is whose experience to trust. The person worth listening to isn't the one without a bias. It's the one whose bias was formed on the other side of the purchase, who has lived with these systems a year in, felt where they get clunky, and can tell you what it'll cost to make it all fit together.

There's no setup without that cost. Every tool is a set of tradeoffs, and picking one is really picking which pain you can live with. The goal isn't to avoid that. It's to choose it with your eyes open, before it's wired into everything and expensive to undo.

The cost of not deciding

The risk of leaving this alone usually isn't a dramatic failure. It's that the workarounds start making the decisions.

Here's how that shows up. Every new hire has to be taught the patches, so they don't go away as the team grows, they multiply. Every new tool has to be worked around the existing patches before it can be useful. And when a genuine opportunity comes along, the first question stops being whether it's worth doing and becomes whether the current setup can absorb it. The answer is often no, so the opportunity quietly gets passed on.

None of this shows up as a line on a budget. It shows up as coordination that shouldn't be necessary, and as good ideas that never get past "we can't really do that right now."

A framework for evaluating: patch or redesign

Not every workaround needs to be redesigned. Some patches are perfectly fine to leave in place indefinitely. The goal isn't to eliminate all workarounds. It's to make conscious decisions about which ones to keep and which ones to address.

When you're looking at a specific friction point, a few questions help clarify whether patching or redesigning is the appropriate response:

Will this have to scale with every hire? A workaround one person carries is a quirk; one every new hire has to learn grows with the team.

Is the frequency increasing or stable? A patch that handles a rare edge case is usually fine to keep. One that's being triggered more often as the business grows is a candidate for redesign, because growth will only make it worse.

What breaks if the person who manages this leaves? If a workaround depends on one person's knowledge and there's no documentation or transferability, it's a single point of failure regardless of how well it functions today.

What would the redesign actually involve? Sometimes the fix costs nothing, like changing a handoff or dropping a step, so check for that before reaching for a tool. Other times it's genuinely large. Know the rough scope before deciding.

What you'd gain

As a business grows, there are two ways to carry more work. You add people, or you build something once that carries it for you: a tool, an automation, a custom build.

A hire is a recurring cost, and it adds one person's worth of capacity. A build is mostly paid once, and it works for everyone who touches that workflow. That difference matters most when the same kind of request keeps coming in and gets handled by hand, one at a time. Each one costs you again. Build it once, as a report anyone can run or a request that fills itself in, and the next person gets it for free.

The build is usually slower to start. The first few weeks feel like you'd have been better off just doing the work. But a hire grows with the team, and a build only grows when a new kind of problem comes up, which is far less often. In the first year they can cost about the same. Over three to five years, they're nowhere near it.

When patching is fine

Patching gets a bad reputation, but it's often the correct choice. A few scenarios where leaving a workaround in place is reasonable:

• The friction is minor and stable. It doesn't get worse as the business grows.
• The cost of redesigning significantly outweighs the ongoing cost of the patch.
• The area is likely to change again soon, making a permanent fix premature.
• The team is aware of the workaround and can manage it without undue effort.
• There are higher-priority areas where time and attention would create more value.

Choosing to keep a patch isn't the same as ignoring it. The difference is awareness. A patch you've decided to keep, with a line on the map saying why, gets looked at again whenever the work around it changes. That's fundamentally different from a workaround nobody has examined in two years.

When it's time to act

A few moments make the case for redesign fairly clear:

• Someone asks for another hire to keep up. Before you commit to a new salary, look at what in that workload could be automated or streamlined. Sometimes the hire is still right, but now you know what you're hiring for.
• The same friction shows up across multiple teams. When several teams are working around the same limitation, fixing it once pays off everywhere.
• Routine work keeps getting slower. A quote that used to go out the same day now takes three. Not one bad week, but a steady drag.
• The patch exists because someone can't get to the data. A lot of manual work is just copying information out of one system so it can be used in another. Connecting those systems directly, through an API or something similar, can remove that step entirely.

When you do decide to redesign, the workflow maps from earlier in this series become genuinely useful. You're not guessing at how things work or starting from a blank slate. You have a current picture of the actual workflow, fed by the people who do it, and alongside it a sense of where you'd want that workflow to go. The redesign lives in the gap between the two: that's what tells you exactly where the change needs to happen, and, just as importantly, where it doesn't.

Choosing the size of the change

Redesign doesn't have to mean replacing everything at once. Where you can, fix the highest-impact friction point first and let the next step follow from what you learn.

But sometimes a full rebuild is the right call. Some systems can't be swapped out piece by piece, and running old and new side by side for too long becomes its own patch. When that's the case, the same principle from mapping applies: the people who do the work need to be part of the design from the start, so their concerns shape the new system instead of surfacing after it ships.

The goal isn't a perfect system. It's a system that evolves intentionally alongside the business it supports.

If you're carrying a workaround you're no longer sure is worth it, tell us what it's costing you and we'll help you work out whether it's worth redesigning.