There’s a process that plays out in South African businesses so consistently I could set my watch by it.
The business identifies a need. Someone, usually not in IT, usually not in UX, thinks up a technical solution for that need. It gets briefed in. Quotes come back. Budget gets found. The project starts.
A year later, someone pulls the ROI numbers. And that’s when the CFO starts glaring.
Why the ROI problem starts before the build
The problem isn’t the technology. It almost never is. The problem is baked in long before anyone writes a line of code: at the moment the business decided what to build without properly asking whether they should build it at all.
ROI gets considered before most digital projects. I want to be fair about that. But it almost always gets considered through one lens only: the business case. What will this cost us, and what do we expect to get back?
What almost never gets properly interrogated is the other two lenses.
Does this solve a real problem for the users who’ll actually use it, in a way that’s genuinely more useful and convenient for them? Because if it doesn’t, they won’t use it. And a digital product nobody uses returns exactly nothing.
And do we have (or can we realistically acquire) the skills and operational capacity to actually make this work? Because that question leads somewhere most businesses aren’t ready to go.
The hidden costs no quote covers
Every time you build a web application, you become a software business.
Most businesses aren’t software businesses. SaaS companies understand this model intimately: the development cycles, the version dependencies, the security updates, the constant iteration. It’s their entire operational reality. For everyone else, it comes as a surprise.
Here’s what the quote almost never covers:
Six months after launch, you’ll need changes. That’s not pessimism; that’s the nature of software in a real operating environment. A year in, you’re likely looking at a partial rewrite of something. And running alongside all of that is the invisible cost that nobody budgets for: the staff time absorbed by the thing just existing. The workarounds people quietly build around its limitations. The person who becomes the unofficial system owner because nobody else knows how it works.
That’s the iceberg. The quote shows you the tip.
The zombie project that quietly drains budget
And then there’s the zombie project.
Not dead enough to kill. Not alive enough to justify. Doing half a job, still consuming budget, still requiring someone’s time, but not returning anything meaningful. And because it’s not quite bad enough to switch off, it just keeps going. The same assumptions that created it become the reason it survives.
If a project genuinely isn’t returning on its investment, the right answer is to stop it. That’s a hard conversation, but it’s the honest one. If it is returning, you at least have a basis for budgeting the ongoing changes and maintenance properly. The difficult situation, the one I see most often, is the one in the middle. Half working. Half justified. Quietly draining resources while everyone waits for someone else to make the call.
Three things that have to be true before you spend
Before any of this, though (and this is where I’d push any business thinking about a digital project), there are three things that have to be true simultaneously:
The business has a genuine, valuable need. The users have a genuine need that aligns with it. And the organisation has, or can realistically build, the capability to make it work.
Miss any one of those and you’re not evaluating ROI. You’re hoping.
Spend time on the business case properly, not as a formality, but as a real investigation. Do the market research. Very few ideas are truly unique, and there are almost always existing implementations to learn from. Go through the build-versus-buy question seriously. Bespoke solutions are rarely the right answer, and they’re almost always the most expensive one.
Why good projects still fail: no adoption plan
But here’s the thing that gets overlooked even when all of that is done well.
A project can tick every single box (solid business case, real user need, right technology decision, good development) and still fail. Because nobody built the internal framework to make it succeed.
No internal champion. No training. No process change to accommodate the new tool. No adoption plan. The software lands and the organisation just doesn’t absorb it. People default back to email, or spreadsheets, or whatever they were doing before. And then everyone looks at the technology as the failure, when the failure was entirely human and organisational.
Zero return on investment. Again.
Getting a real return on digital investment
I look at digital projects with long eyes. Not because I’m pessimistic about them. I’ve seen genuinely transformative digital work done in South African businesses. But because the businesses that get real returns are the ones that go in with their eyes open: about what it will actually cost, what it will actually take to run, and whether their organisation is genuinely ready to make it work.
That conversation, before the brief, before the quote, before the budget meeting, is worth more than any post-mortem.
Garth Shoebridge is a digital problem-solver with 25 years of experience helping South African businesses think clearly before they build. If you’re about to commission a digital project, or you’re sitting with one that isn’t returning what it should, start with a conversation.