The business has outgrown its systems. Everyone knows it. The decision has been made: it’s time to build something properly.
So the next step is finding a developer. Right?
Not quite. Or at least — not yet.
The businesses that get the best results from software development projects aren’t necessarily the ones that find the best developer. They’re the ones that are clear on what they need before a developer gets involved. That clarity is rarer than it sounds — and the absence of it is the single most common reason projects run over budget, miss the mark, or get quietly shelved.
Hiring a developer before you know exactly what you need is a bit like hiring a builder before you have the architect’s drawings. The work might start quickly. But you’ll pay for the gaps later.
Question 1: Do you know what problem you’re actually solving?
This sounds obvious. It almost never is.
Most businesses come to software development with a solution already in mind: “we need a portal,” “we need an app,” “we need to integrate our systems.” That’s a starting point, not a brief. The real question is: what is the underlying problem, and is the proposed solution actually the right one?
A good developer will build what you ask for. A good technology advisor will challenge the brief before a line of code is written — because sometimes the right answer is a simpler process change, a different integration, or a phased approach that costs a fraction of what was originally planned.
“The most expensive software is the software that solves the wrong problem.”
If you can’t answer ‘what does success look like in six months’ in one sentence, you’re not ready to brief a developer yet.
Question 2: Have you mapped your processes before trying to automate them?
Software doesn’t fix broken processes. It automates them. If the way your team handles customer onboarding, order management, or compliance reporting is inconsistent or poorly documented, a new system will encode that inconsistency and make it harder to fix later.
The businesses that transition most smoothly are the ones that have done the process work first — even informally. They know how things currently work, where the gaps are, and what ‘better’ looks like in practice. That process knowledge shapes the build and keeps the project grounded in operational reality rather than wishful thinking.
This matters even more in regulated environments. If your business operates in financial services, professional services, or any sector with audit or compliance requirements, the way your processes are documented — and the way your system supports that documentation — is not an afterthought. It’s a core requirement that needs to be built in from the start, not bolted on later.
A developer can build you a system. They can’t tell you what your processes should be. That’s a different conversation entirely.
Question 3: Who will own this when it’s built?
Software needs ongoing attention. Requirements change, issues arise, the business evolves. Someone needs to be responsible for the system after go-live — managing the relationship with the developer, making decisions about what gets built next, ensuring the system keeps pace with how the business is changing.
In larger organisations, that’s the CTO. In most SMEs, there isn’t one. Which means the responsibility tends to fall on whoever is least busy at the time — which is rarely the right person, and rarely sustainable.
Before you commission a build, be honest about who will own it. If the answer is ‘we’ll figure that out,’ that’s a risk worth taking seriously. Technology decisions made without clear ownership tend to drift — and drifting technology becomes expensive technology.
The system is only as good as the person steering it. If that role doesn’t exist yet, it needs to.
Question 4: What does the support relationship look like after launch?
A common and painful pattern: a business commissions a piece of software, the project goes reasonably well, the system goes live — and then six months later, something needs changing and the developer is unavailable, expensive, or no longer interested in a small piece of work.
Before you hire anyone, understand what the ongoing relationship looks like. Is there a support arrangement? Who do you call when something breaks? What’s the process for requesting changes, and what will they cost? How long has this developer or agency been operating, and what’s the realistic chance they’re still around in three years?
For SMEs, the ongoing relationship is often more important than the initial build. A system that works well on day one but becomes impossible to maintain or develop is not a success — it’s a problem deferred.
“The question isn’t just ‘can they build it.’ It’s ‘will they still be there when you need them.'”
Question 5: Is a developer actually what you need first?
This is the question most businesses don’t think to ask — and it’s the most important one.
What many growing SMEs actually need, before they hire a developer, is someone who can help them think clearly about their technology: what to build, what to buy, what to integrate, and in what order. Someone who understands both the business problem and the technical landscape — and can translate between the two.
That’s what a Fractional CTO does. Not a full-time hire — most SMEs don’t need or want that — but an experienced technology leader who works with the business on a part-time or project basis, providing the strategic clarity that turns a vague technology ambition into a clear, costed, deliverable plan.
The businesses that get this right don’t start by hiring a developer and hoping for the best. They start by getting clear on what they need — and then commissioning the build with confidence, knowing the brief is solid and the investment is sound.
What this looks like in practice
At Maly, we work with SMEs across Suffolk and Essex at both levels: the strategic conversation about what to build and why, and the hands-on delivery of the systems themselves. For businesses that aren’t ready to commission a full development project yet, our Fractional CTO service is often the right starting point — a practical, affordable way to get the technology thinking in place before any money is spent on development.
It’s not the most obvious entry point. But for businesses that have been burnt before, or that want to get this right first time, it’s often the most valuable one.
We’re Maly IT Solutions — based in Suffolk, working with SMEs across East Anglia and Essex. We offer Fractional CTO support for businesses that want senior technology thinking without the full-time hire, as well as end-to-end bespoke software development for when the brief is clear and the build is ready to begin.
If you’re at the stage of ‘we know we need to do something, but we’re not sure what’ — that’s exactly the conversation we’re set up to have. Free 30-minute call, no commitment.
📧 hello@maly.co.uk 📞 01473 934672 🌐 maly.co.uk
This is article 3 in The Systems Gap — a four-part series for SMEs who know their systems need attention but aren’t sure where to start. Read article 1 here.