If you’re running a medium-sized business, most of your technology problems probably don’t arrive as one big, obvious “software problem”.
They creep in.
A spreadsheet appears because two systems don’t quite talk to each other. Someone spends an afternoon every month pulling together a report. A platform that was fine five years ago now needs three integrations and a few workarounds to keep doing its job. There’s an idea for improving the customer experience, but implementing it with the systems you have feels harder than it should.
None of these things is necessarily disastrous, and that’s partly why they’re so easy to live with.
But eventually, a business can reach a point where the software that was meant to make things easier has quietly become part of what’s slowing it down.
Medium-sized businesses sit in an awkward middle
Off-the-shelf software makes a lot of sense, a lot of the time. It’s quick to implement, the upfront cost is predictable and someone else is responsible for maintaining the product.
Our advice has always been, if it does what you need, then you should use it.
The challenge for a medium-sized business however, is that you’re no longer particularly simple. You’ve got established processes, customers, data, systems and ways of doing things that have developed over years. There may be good commercial reasons why your business works differently from the competitor down the road.
At the same time, you probably don’t have endless internal technology capacity. Your IT, digital or operations people likely already have a list of things they could fix if they had another day in the week.
That can leave you in a slightly uncomfortable spot. Your business is becoming too complex for some standardised software to fit neatly, but building something specifically for you may still feel like the sort of decision only much larger organisations make.
That assumption is worth revisiting.
The cost you see isn’t always the cost you have
When businesses compare off-the-shelf software with custom development, the obvious place to start is price.
One has a licence fee. The other comes with build and maintenance costs.
But that isn’t the whole calculation.
Many of the medium-sized organisations we work with are all too aware that members of their team are spending hours every week moving information between systems, holding things together with spreadsheets or engaging in slightly complex and fragile workarounds - but lack either the capacity or capability to unpick those challenges. Nobody is necessarily recognising this as a software cost. It’s just sitting inside payroll or looking like a productivity challenge.
Scenarios we’ve seen or experienced include; CRM products that “almost fit” your sales process, so the team has developed a separate spreadsheet to handle the part it doesn’t. A critical system that is difficult to change because only one or two people really understand how it works or the technology is so old modernising it has felt too scary to tackle. In the meantime it keeps running, so there’s no urgent reason to replace it. But the key person or technology risk is quietly accumulating.
Then there are the things that are harder to put a number on: ideas that never get off the ground, services that are difficult to introduce, frustrated customers having to work around clunky processes, or experienced people spending their time administering systems and maintaining spreadsheets rather than doing the highest-value work you could have them addressing.
This is where off-the-shelf software can become deceptively expensive. Not because the licence itself costs too much, but because the compromises around it start accumulating.
We ran our own software consultancy this way for years. A stack of general-purpose tools that didn't talk to each other, that were never built for the particular shape of our business or our unique context. For example, our CRM had no concept of the sectors we actually work in - no categories for Crown Entities or an iwi organisation. No appreciation for the nuances of government procurement cycles, where a contact goes quiet for six months because a live process is underway rather than because they've lost interest, but it looked identical to a cold lead.
None of this was catastrophic. All of it was quite rational given the costs and choices in play. But gradually it did become friction, accumulated over years, accepted because fixing it was expensive and complicated.
Then, quite suddenly, it wasn't.
When your software starts shaping your business
There’s another cost that’s easy to miss.
Sometimes businesses gradually change the way they work to suit the software they bought. That isn’t necessarily a problem. Plenty of processes or business functional needs simply aren’t special, and there’s little value in reinventing them.
But what if the process you’re compromising is valuable?
Perhaps your service model is different from your competitors’. Maybe there’s something unusual about how you price, schedule, fulfil, analyse data or work with customers. Those differences may be part of what makes the business successful.
If standardised software keeps asking you to remove those differences, it’s worth asking which thing should move: the business or the software?
For years, the answer was often the business. Custom development was expensive enough that adapting your processes would still be the sensible commercial choice in most cases.
But, that calculation has also changed. There is now an incredible opportunity to innovate and differentiate by owning the workflows and patterns which are your organisation’s unique ways of working.
Why this is worth looking at again now
We’ve written separately about how AI is changing the economics of software development and what that means for the cost of building digital products.
The short version is that capable software teams can now move faster through parts of research, design, development and testing than they could a few years ago. That doesn’t make good software effortless, and it certainly doesn’t make every idea worth building.
What it does mean is that some projects which previously struggled to stack up commercially are worth another look.
We tested this claim on ourselves before making it to anyone else. Earlier this year we built our own internal operating system on exactly this logic: custom-built for how we actually work, not adapted from someone else's data model. It took weeks, not months, and it wasn't painless. Things broke. A formatter miscalculated a figure by a hundred times before anyone caught it. A sync bug meant an evolving client conversation stopped producing fresh updates after the first message came through. Real software has rough edges, AI-assisted or not, and pretending otherwise isn't credible. But, fixing those issues, getting things exactly right is now faster and easier than it ever has been before.
That matters for medium-sized businesses because custom software doesn’t have to mean embarking on a massive transformation programme or replacing everything you already have.
Sometimes the right opportunity is much, much smaller.
You probably don’t need to replace everything
When people hear “custom software”, they often imagine a large new platform replacing half the technology in the business.
It really shouldn’t look like that. In fact, while the cost of creating and maintaining software has reduced - the effort required to define, test and adapt to new systems has not. There are absolutely still very human constraints to how fast you can or should transform your business.
The approach we’ve taken ourselves - and try to recommend to others - is to start where you can release team capacity or reduce significant costs first. That might look like connecting two systems so your people stop transferring data manually. It might be automating one high-volume process that has quietly become a full-time job. It could mean modernising one ageing piece of software before it becomes a genuine operational risk. Normalise making small, incremental improvements which make things better - and the change management and human adaptation elements become infinitely easier.
The point isn’t to find an excuse to build custom software. It’s to stop assuming that buying another product is automatically the cheaper or safer answer.
Sometimes you need to build. Sometimes you need to integrate. Sometimes you need to improve what you already have. And sometimes the best answer is to leave things alone.
Look for the work your business has stopped noticing
A useful place to start is with work that has become so normal nobody questions it anymore.
Which reports are still assembled manually every week or month? Where is information copied from one system into another? Which spreadsheet would cause genuine panic if it disappeared tomorrow? What processes depend on somebody remembering the next step?
Individually, these tasks can look trivial. Across a team, over a year, they’re often anything but.
The approach we’re advocating for is that this isn’t about cutting people. It’s about giving good people more time to do the most useful work inside an organisation. In many medium-sized businesses, capacity is already the constraint and some of your most motivated and talented team-members are spending far too much of their time on low value tasks.
That’s where the commercial case becomes much more interesting.
Find the systems that are quietly becoming a risk
There’s another pattern we see in established businesses: software that works perfectly well, provided nobody touches it - or software that relies on one or two people’s knowledge to keep it working.
Maybe it was built years ago. Perhaps the person who originally knew it inside out has left - or is approaching retirement. Maybe it has accumulated integrations and fixes to the point where changing one thing risks breaking three others. Maybe you simply cannot find a software developer to work with that language or framework any more.
You don’t necessarily need to rip these systems out. In fact, that may be the worst possible answer. But you do need to understand how much business risk is sitting inside them and whether there’s a sensible path to modernising them before the decision gets made for you.
Separate frustration from opportunity
Not every process deserves custom software.
If a workaround costs the business a few hundred dollars a year, live with it. If an off-the-shelf product solves 90% of the problem and the remaining 10% doesn’t materially affect the business, that’s probably still the right call.
The better questions to ask are practical: what does this cost you each year? Is it limiting growth, capacity or customer experience? What would solving it unlock that you can't do today?
Then compare that with what addressing the issue would actually require.
That’s a much more useful conversation than arguing about whether custom software is ‘better’ than SaaS for your business, remembering the answer isn't only build or buy. It might be configuring what you have, better connecting two systems, replacing one weak link, or building something small and unique. All of those options are more realistic now than they were even two years ago.
Before you commit, pressure-test the problem
The first step doesn’t need to be a software project. In fact, it probably shouldn’t be.
Start with the thing that isn’t working as well as it should. Understand what it’s actually costing you, who it affects and what a better version would unlock.
That’s exactly the kind of problem we like working through at MadeCurious, whether that means building something custom, improving what you already have or deciding not to build at all.
Because the interesting question isn’t “Can a medium-sized business afford custom software?” It’s “What is the current way of doing this already costing us?”
Wondering whether custom software could make sense for your business?
The economics have changed, but the right answer still depends on the problem you’re trying to solve. See how MadeCurious approaches software for medium-sized businesses, and what your options could look like.
