The Real Cost of Bending a System to Do What It Wasn't Built For

Every organization has one. A system that was designed for one purpose and quietly conscripted into doing another. A CRM repurposed as a project tracker. An accounting platform doubling as an inventory system. A scheduling tool holding data it was never meant to hold.

It usually starts with good intentions and a reasonable-sounding justification: we already have this tool, we're already paying for it, it can probably handle this if we set it up correctly. Let's avoid the cost of buying something new.

What follows is one of the most reliably expensive decisions in enterprise technology.

The visible cost and the real cost

When an organization bends a system out of shape, the visible cost is zero. No new license. No new vendor. No capital expenditure to justify to the CFO. On paper, it looks like the efficient choice.

The real cost shows up elsewhere — in places that don't have a line item in the technology budget.

It shows up in staff hours. When a system doesn't do what people need it to do, people compensate. They build workarounds. They export data to spreadsheets and manipulate it manually. They develop institutional knowledge about the quirks of the system — knowledge that lives in people's heads, not in documentation, and that walks out the door when those people leave.

It shows up in errors. Systems doing things they weren't designed for tend to fail in ways that are hard to predict and harder to debug. An e-commerce platform that can't track inventory in real time doesn't fail loudly with an error message. It fails quietly, by allowing customers to purchase products that aren't in stock, generating a cascade of downstream problems that are expensive to fix and corrosive to trust.

It shows up in opportunity cost. A team spending 30% of its capacity managing workarounds for a poorly fitted system is a team that isn't building, improving, or growing.

A concrete example

At the Muttart Conservatory during COVID-19, the cost of bending a CRM into an e-commerce platform was not abstract. It was staff working overtime every day to manually reconcile online orders against physical inventory — because the system had no mechanism to do this automatically. It was customers receiving confirmation emails for plants that were already sold. It was a customer service burden that grew with every transaction.

None of these costs appeared on a technology invoice. They appeared on the payroll. They appeared in customer complaints. They appeared in the exhaustion of a team being asked to compensate, with human labour, for a system that was simply wrong for the job.

When I replaced the CRM workaround with Shopify — a platform designed specifically for e-commerce — the overtime stopped immediately. Not because Shopify is magic, but because using a tool for what it was built for means the tool does the work, not the people.

How to read the real cost before you commit

The time to identify a bad system fit is before the project starts, not after. Here are the questions I ask:

What will this system do that it was not originally designed to do? Be specific. List every function you're asking the system to perform that falls outside its original design. For each one, ask: how will the system handle this natively, and what will happen when it can't?

What manual processes will this create? Every gap between what the system does and what you need it to do will be filled by a person. Map those gaps before you start. Estimate the time cost honestly.

What happens when it breaks? Systems doing things they weren't built for tend to break in unexpected ways. Who will debug it? How long will it take? What's the impact on operations while it's broken?

What's the exit cost? If you realize in six months that this isn't working, how hard is it to migrate to a better solution? Data that lives in a system it wasn't designed for tends to be messy, poorly structured, and difficult to extract cleanly.

What would a purpose-built solution actually cost? Get the real number — licensing, implementation, training. Compare it honestly to the fully-loaded cost of the workaround, including staff time, error rates, and opportunity cost. You may find the "free" option is the expensive one.

The organizational bias toward the familiar

One of the reasons this happens so frequently is that organizations have a strong bias toward tools they already own and understand. There's a comfort in the familiar, even when the familiar is wrong for the job. There's also organizational friction attached to buying something new — procurement processes, budget approvals, change management.

These are real constraints. But they are costs of doing things correctly, not arguments for doing things incorrectly. The friction of procurement is a one-time cost. The friction of a poorly fitted system is a recurring cost that compounds over time.

My job, when I'm working with a client, is to put both numbers on the table — honestly — and help them make the right call. Sometimes that means recommending a new tool. Sometimes it means finding a way to make the existing tool work without bending it past its limits. And sometimes it means building something custom, because nothing that exists fits the requirement.

But it always starts with an honest assessment of what the system can actually do — not what someone hopes it can be made to do.

That's the conversation that saves organizations money. It's also the one that's most often skipped.