This is Article 3 in the SME Insights Season 2 series. Read Article 1 | Read Article 2
There’s a question I ask every business I work with. It’s simple, but the answer is almost always revealing.
“Does your software support the way you work — or have you changed the way you work to fit your software?”
Most people pause when they hear it. Then they start listing things. A step they added to satisfy a dropdown menu. A report they stopped producing because the system couldn’t generate it. A client-facing process they simplified — not because it was better for the client, but because it was the only way to make the system record it correctly.
The software was supposed to serve the business. Somewhere along the way, it quietly became the other way around.
This is the third article in a series about the hidden costs of software that doesn’t quite fit. In the first two, I looked at how workarounds accumulate and what they actually cost in time and money. This time I want to talk about something subtler — and in some ways more damaging. What happens when a business stops doing things its way, and starts doing things the software’s way instead.
The slow drift you don’t notice
It rarely happens all at once. Nobody makes a conscious decision to redesign their business around a piece of software. It happens in small steps, each one reasonable in isolation.
A new system is introduced. It doesn’t quite handle one part of the process, so that part gets adjusted slightly. Then another part. A field that doesn’t exist in the system stops being recorded. A check that used to happen at a certain point in the workflow gets moved because the system triggers it differently. A client gets a slightly different experience because the system makes the old experience difficult to deliver.
None of these changes feel significant individually. But over two or three years, the cumulative effect can be substantial. The business has quietly reshaped itself — its processes, its client experience, its internal standards — around the constraints of a system that was never designed specifically for it.
This is what I call process drift. And it’s dangerous precisely because it’s invisible. The business still works. It just no longer works quite the way it did — or the way it should.
Why it matters more than it looks
You lose what made you good. Most SMEs have a way of doing things that’s developed over years — a particular thoroughness, a specific client experience, an unusual level of care at a certain point in the process. These are often competitive advantages, even if they’re not labelled as such. When software quietly removes them or makes them impractical, the business loses something real — something that clients noticed and valued, even if they couldn’t articulate it.
You become dependent on a system that doesn’t fit. The more your processes are shaped around a particular piece of software, the harder it becomes to change it. The system has become load-bearing in ways that weren’t planned and aren’t well understood. When it eventually needs replacing — and it will — the transition is far more painful than it needed to be.
Your people stop questioning it. Once a process has been in place for a year or two, it starts to feel normal. New team members learn “this is how we do things here” without ever knowing it wasn’t always that way. The original reason for the change — the software constraint — is long forgotten. What remains is a process that nobody chose and nobody would choose today.
A business introduces a new CRM or job management system. The system has a standard workflow that doesn’t quite match how they handle client onboarding — there are a few extra steps, some specific to their sector, that the system doesn’t have fields for. Rather than configuring the system or building something bespoke, the team quietly drops the extra steps. Two years later, a long-standing client mentions that things “used to feel more thorough.” The business owner can’t quite remember when it changed — or why.
The buy vs. build question — asked too late
When a business needs a new system, the default is to look for something off-the-shelf. That’s completely understandable. It feels lower risk, lower cost, faster to implement. And sometimes it’s absolutely the right call.
But the question of whether to buy or build — or buy and customise, or use a hybrid approach — needs to be asked with a clear understanding of what your processes actually are and where they’re genuinely distinctive. Without that understanding, you’re making a significant long-term commitment based on incomplete information.
The questions worth answering before committing to any system are:
- Which parts of the way we work are standard — and which are specific to us?
- Where would adapting our process to fit a system cost us something real — in client experience, quality, or competitive advantage?
- What’s the long-term cost of a system that’s 80% right, versus the upfront cost of something built properly for us?
- If we implement this system, what will we have to stop doing — and are we comfortable with that?
These aren’t technical questions. They’re strategic ones. And they’re exactly the kind of questions that benefit from someone with both technology experience and business understanding — someone who can look at the whole picture before a commitment is made.
The best time to ask these questions is before you sign the contract, not eighteen months after go-live.
What good looks like
The businesses I work with that have the healthiest relationship with their technology tend to share a few things in common. They know which of their processes are distinctive and treat them as worth protecting. They’re deliberate about what they’re willing to adapt and what they’re not. When they bring in new technology, they make an informed choice — and they understand the trade-offs they’re accepting.
That clarity doesn’t come automatically. It comes from stepping back and looking at the business with fresh eyes before making technology decisions — rather than after.
This is a significant part of what I do when I work with businesses in a Fractional CTO capacity. Not just assessing the technology, but understanding the processes underneath it — which ones are load-bearing, which ones have drifted, and which ones deserve to be built into a system properly rather than worked around.
It’s the kind of thinking that pays for itself quickly. Not in code, but in avoided mistakes.
A question worth sitting with this week
Think about one thing your business used to do — a step in a process, a standard you held, a way of handling clients — that quietly disappeared or changed when a new system came in.
Was that change a conscious decision? Or did it just happen because the system made the old way difficult?
And if you could go back — would you make the same call?
I’m Richard, co-founder and CTO of Maly IT Solutions, based in Suffolk. As well as building bespoke software for SMEs across East Anglia, I work with business owners in a Fractional CTO capacity — helping them think clearly about technology decisions before committing to them, and making sure their systems support the way they work rather than the other way around.
If any of this resonates, I’d be glad to have a conversation. The first step is usually just mapping where you are — no commitment, no pitch.
Free 30-minute call to start that conversation.
📧 hello@maly.co.uk | 📞 01473 934672 | 🌐 maly.co.uk