You're solving the right problem - but asking the wrong first question

Most SMEs do not make poor technology decisions because they run out of options. They make them because they reach for the answer before they understand the problem.

Picture a regional logistics company - eight drivers, a small ops team. Deliveries are slipping. Customers keep calling about ETAs. The owner is holding everything together with WhatsApp, a printed run sheet, and a shared spreadsheet. Someone says: "We need a delivery management system." Within a month, the business is sitting through demos for tools that cost more than the problem has ever been clearly defined.

What no one has asked is the more uncomfortable question: when a delivery is rescheduled, who is supposed to update the customer, and where does that decision actually live?

No software answers that until the business does. That is where expensive mistakes start.

Build versus buy is a real debate. But it is rarely the first decision. The first decision is whether the business has properly understood what it is trying to fix.

Software amplifies the process you already have

SMEs usually start looking at software for one of two reasons: the current way of working feels too manual or fragmented to scale, so a new tool seems like the next logical step. Or there is already software in place, but the underlying process still is not working, and the assumption is that a different platform will fix it.

Both instincts are reasonable. Software does help. But it tends to amplify whatever process it is dropped into. Where ownership is clear and the workflow is consistent, software makes a decent setup better. Where exceptions are handled ad hoc and nobody is quite sure who owns what, a new platform usually formalises the mess rather than resolving it.

This is how businesses end up paying to encode a broken process, configuring a platform into something fragile, or building custom logic around a workflow that was never properly specified.

The question is not whether software matters. It is whether the business has enough operational clarity to choose well - and to actually use whatever it picks.

Three paths, three trade-offs

Buy means adopting an off-the-shelf tool and adapting parts of how you work to fit it. Fastest and lowest-risk when the problem is common and already well solved by the market.

Configure means taking a flexible platform and shaping it around your workflow, without writing software from scratch. Works best when you need more flexibility than a fixed product offers, but not full bespoke development.

Build means commissioning custom software for a workflow standard tools cannot support. In most SMEs, this rarely means a full replacement; it is usually a targeted layer sitting around the tools already in use.

None of these paths is inherently better than the others. They differ in speed, fit, ownership burden, and what they cost to maintain over time. In most SMEs, the right answer is not to replace everything. Keep what already works, identify where the real friction sits, and address those gaps deliberately.

The questions that come before the vendor list

Before comparing platforms or scoping a build, a handful of honest questions usually make the right path clearer than any product demo will:

When each path fits

1. Buy

Buying makes sense when the process is common, well understood across your sector, and not central to how you compete. Payroll, accounting, standard invoicing, and email marketing usually sit here. The value comes from reliability and speed, not from tailoring every detail.

Take the example of a 45-person professional services firm that spent the better part of a year evaluating HR platforms. The founder was convinced their culture demanded something bespoke: flexible appraisal cycles, custom onboarding tracks, peer recognition built in. After months of demos, they adopted BambooHR off the shelf, configured it in three weeks, and went live. Six months on, voluntary turnover had dropped noticeably, not because of anything sophisticated in the software, but simply because automated reminders meant managers were finally completing reviews on time and new joiners had a structured first 90 days. The tool enforced consistency the business had never managed manually.

Buying works when the business is willing to accept the trade-off: speed and reliability in exchange for adapting some of how you work to fit the tool's assumptions.

2. Configure

Configuration is the path SMEs most often overlook. It fits when the workflow is somewhat specific but not radically unique, the process is still evolving, the platform's data model is close enough to what you need, and someone in the business can own the setup over time.

One property management company running 400 units had outgrown spreadsheets but found every purpose-built platform either too rigid or far too expensive. Rather than buy a specialist tool, their operations manager spent six weeks building inside HubSpot: separate pipelines for move-in, maintenance escalation, and move-out, with automated document-chase sequences and a direct connection to their accounting system. The setup was not glamorous, but it eliminated the daily "what's the status?" calls between the lettings and accounts teams entirely, and average days-to-resolve on maintenance jobs dropped from 18 to 11 over the following quarter.

For growing SMEs, configuration often strikes the right balance: flexibility without the full burden of custom software. It is also where the most valuable near-term improvements usually sit: better handoffs, clearer ownership, tighter data capture, sharper reporting.

3. Build

Building earns its place when a process is genuinely important enough to justify it: truly specific to how the business operates or competes, where standard tools would force too many compromises and the cost of workarounds has become significant.

Consider a wholesale food distributor with around 80 staff. Their off-the-shelf inventory system was handling stock recording well enough. The real gap was replenishment: the buying team could see current stock levels, but had no support for deciding what to reorder, when to reorder, or where overstock risk was quietly building. They were losing roughly 6% of margin annually to a combination of stockouts on fast-moving lines and write-offs on slow ones. Replacing the inventory system would have been disruptive and unnecessary. The better answer was to keep the core platform and build a targeted layer on top of it, pulling stock movement data, applying simple forecasting logic, and surfacing reorder prompts with confidence scores to the buying team each morning. Within two buying cycles, the stockout rate on their top 40 lines had halved and write-off volume dropped by a third.

The worst custom software is software built around a problem the business never properly defined.

Build should follow clarity, not stand in for it.

Where SMEs trip up

These are not just technology mistakes. They are execution mistakes. A software decision only works if it reflects how the business actually runs. And how it intends to run as it grows.

The costs that don't show up on the invoice

Every path has visible costs and quieter ones. For lean SMEs, the quiet ones are often the ones that do real damage.

With build, the obvious cost is development. The hidden ones are bug fixing, upgrades, documentation, security obligations, and the technical debt that compounds when no one is funded to clean it up. One logistics firm commissioned a custom driver allocation tool at significant cost. Eighteen months later, the original developer had moved on, no one internally understood the codebase, and a routine change to shift patterns required a four-week external engagement to implement. What had looked like a one-time investment had become an ongoing liability.

With buy, the obvious cost is the subscription. The hidden ones are process compromise, data migration, switching friction, and the steady tax of adapting to the vendor's model. A 60-person accountancy practice adopted a cloud bookkeeping platform that structured client engagements differently from how the firm had always worked. The software was technically sound, but it took two years of manual reconciliation between the platform and their existing reporting before the firm accepted the switch had not worked and moved again - having paid for both systems throughout.

With configure, the upfront cost looks moderate - but the real cost surfaces later: configuration sprawl, dependence on one internal expert, and complexity that grows quietly until that person leaves. A retail business with three locations had built an intricate set of automations inside their e-commerce platform over three years. When the ops manager who had built and maintained it resigned, the business discovered that no one else understood how it worked, two of the automations had been silently failing for months, and untangling it took longer than rebuilding from scratch would have.

Underneath all three sit the operational costs SMEs routinely miss: manual reconciliation between systems, inconsistent reporting, exceptions handled outside the workflow, slow decisions where ownership is unclear, and workarounds that quietly become permanent.

The real question is not what is cheapest to buy. It is what is cheapest to get right - and to maintain.

The honest answer is usually hybrid, and sequence matters

In practice, most SMEs do not end up purely in one camp. They buy where the process is standard. They configure where the workflow needs more fit. They build selectively where the gap is real and important enough to justify it.

But the sequence matters. Start with process clarity: understand what is actually broken and who owns it. Then buy what is already standard and well-solved. Only configure where your workflow genuinely diverges. And build only where the gap is both real and load-bearing to how the business competes.

Not every problem needs a new platform. Not every gap justifies a rebuild. Often the smartest decision is to preserve what works and solve only what is genuinely missing.

Back to the logistics company

The regional logistics business from the start of this piece eventually did buy a delivery management system, but not before working out the answer to that uncomfortable question: when a delivery is rescheduled, the dispatcher owns the customer update, and it happens within 30 minutes via a templated WhatsApp message, logged in a shared sheet.

That single process decision - four sentences, zero software - reduced customer calls about ETAs by roughly half before any new tool was in place. When the delivery management system arrived, it worked, because the process it was amplifying was finally clear.

That is what good technology decisions look like in practice. Not a grand replacement programme. A clear process, followed by the right-sized tool to support it.

In short

For most SMEs, the biggest technology mistake is not picking the wrong vendor. It is committing to a path before the business is clear on the process, the ownership, the exceptions, and the trade-offs.

Build, buy, and configure can each be the right answer in the right context. So can a simpler version of the question: keep the core, fix the operational gaps, and build only where standard tools genuinely fall short.

Good technology decisions do not start with software. They start with knowing how the business actually runs.