There is a moment, familiar to anyone who has managed a growing South African organisation, when a spreadsheet stops being a tool and starts being a threat. Data lives in twelve different tabs. Two people updated the same row. The formula that used to work no longer does, and nobody knows why. Reporting takes a day instead of twenty minutes. A staff member has left and taken their institutional knowledge of the filing system with them.
The natural response is to commission software. And that response is usually correct — but the timing of it is almost never right. Organisations reach for a solution before they have clearly defined the problem, and they pay for that confusion in months of delays, scope creep, and systems that do not quite fit.
After more than a decade of building bespoke systems for South African organisations — from NGOs managing multi-country M&E programmes to SMEs running complex fleet and workshop operations — we have seen this pattern more times than we can count. This article is our attempt to give you the thinking that should precede the commission, so that when you do bring in a development partner, the engagement starts on solid ground.
Know the difference between a symptom and a problem
The most common brief we receive goes something like this: "We need a system to manage our reporting." Or: "We need something to replace Excel." Or: "We need a portal for our field teams." These are symptoms — observable frustrations that point toward a problem. They are not the problem itself.
The problem is always more specific. It might be that your operations manager spends twelve hours a week manually consolidating data that should consolidate automatically. It might be that your donors receive reports three weeks late because the data extraction process requires a qualified analyst. It might be that your field teams cannot capture data without a reliable data connection, so they fall back on paper and then spend two days on re-entry.
Before you commission anything, you need to be able to state the actual problem — the workflow that breaks, the decision that cannot be made, the cost (in time, money, or risk) of the current situation. If you cannot state it clearly, the brief you give your developer will be vague, and vague briefs produce expensive misunderstandings.
Map the process before you automate it
Software automates processes. This is its primary value. But if the process it automates is poorly designed, the software will be efficient at doing the wrong thing — and it will be much harder to change once it is built into a system than it was when it lived in a spreadsheet.
The discipline of process mapping — sitting down with the people who actually do the work and tracing exactly what happens, in what order, with what information, and who touches it at each step — is unglamorous. Most organisations skip it. But it is the single most valuable thing you can do before writing a brief, because it surfaces three things that developers need and that you cannot discover any other way: the exceptions that occur in practice but not in theory, the informal workarounds that staff have invented because the official process does not quite work, and the handoff points where data changes hands and can be lost or corrupted.
A good process map does not need to be a formal BPMN diagram. It can be a whiteboard session. But it needs to happen, and it needs to involve the people closest to the work — not just the manager who thinks they know what their team does.
Be honest about your data
Custom software is only as good as the data it works with. This is a statement that development companies rarely make to prospective clients, because it tends to complicate the sale. We make it anyway, because finding out mid-build that the underlying data is unusable is considerably more expensive than addressing it at the outset.
Before you commission development, you need to audit what you actually have. Where does your data live? Is it in one place or many? Is it structured consistently, or have different staff members formatted things differently over the years? Are there duplicates? Are there gaps? If you are migrating data from an existing system into a new one, what is the quality of that data, and who is responsible for cleaning it?
Data migration is one of the most frequently underestimated components of any software project. A system can be technically flawless and practically useless if the information it contains is unreliable. Budget for data work. Allow time for it. Do not assume it will sort itself out.
Identify your real stakeholders — including the ones who will resist
A new system changes how people work. That is the point. But it also means it will encounter resistance — sometimes from people with legitimate concerns about the impact on their role, sometimes from people who have built personal authority around being the keeper of institutional knowledge, and sometimes simply from people who do not like change and have enough organisational standing to slow things down.
Before you commission development, map your stakeholders honestly. Who has to use this system for it to work? Who has the authority to block its adoption? Who needs to be involved in defining requirements, even if they are not the primary users? Who in your IT environment — whether that is a person or a service provider — needs to be consulted about infrastructure, security, and integration?
None of these people need to be decision-makers in the project. But they need to be identified early and managed deliberately. The projects we have seen derailed at the point of rollout are almost always ones where a key stakeholder was not consulted early enough and became an obstacle rather than a champion.
Have a realistic sense of what it should cost — and what you can sustain
Custom software in South Africa at professional quality does not cost what people expect it to. It costs more. A senior development team billing honest rates will charge somewhere between R800 and R1,500 per hour depending on the complexity of the work, the seniority of the team, and the specifics of the engagement. A modest but well-built system — a proper management information system, a functional CRM, a data portal with reporting — typically represents R250,000 to R500,000 or more in development investment.
That is not a complaint about pricing; it is the cost of building things that last. The problem arises when organisations commission development expecting it to cost a third of that, receive a quote that reflects reality, and then look for a cheaper alternative that delivers a fraction of what they actually need.
Equally important is the ongoing cost. Software requires maintenance, hosting, updates, and support. A system built on Microsoft Azure will carry monthly infrastructure costs. A system that integrates with third-party platforms will need someone to manage those relationships as APIs change. Budget for the full lifecycle, not just the initial build, or you will find yourself in eighteen months with a system you cannot afford to maintain.
The projects that deliver on time, within budget, and without significant scope creep are almost always the ones where the client arrived with a clear problem statement, a mapped process, and a realistic budget.
A word on off-the-shelf alternatives
Before commissioning custom development, it is worth asking honestly whether you actually need it. The South African software market has matured considerably in the past decade. There are now credible off-the-shelf options for CRM, project management, HR, accounting, field data collection, and basic M&E that would have required custom development five years ago.
Custom development is justified when your processes are genuinely distinctive — when the way you operate is sufficiently different from the norm that a general-purpose tool cannot accommodate it without significant compromise. It is also justified when you need deep integration between systems that do not natively communicate, when your data volumes or security requirements exceed what SaaS platforms can accommodate, or when you need to own your data infrastructure completely.
It is not justified simply because you have not looked hard enough at what is available, or because a bespoke system feels more prestigious than an adapted standard one. A good development partner will tell you this. Be wary of one who does not.
What a proper discovery process looks like
In an ideal world, every organisation would work through the five questions above before approaching a developer. In practice, most do not — not because they are negligent, but because the questions are difficult to answer in isolation. They require both internal honesty about how the organisation actually operates and external expertise about what is technically possible and at what cost.
This is the gap that a structured discovery engagement is designed to fill. Not a free scoping call, not a sales pitch dressed up as consultation, but a proper half-day working session with your management and operational teams, led by a senior technical adviser who has no stake in selling you a particular solution.
The output should be a written assessment: your current technology landscape, the processes that are most in need of attention, two or three realistic solution approaches with honest tradeoffs between them, and ballpark investment ranges for each. A document that your board can read, that your finance team can budget from, and that a development team can use as the foundation of a proper specification — not the specification itself, but something that makes the specification possible.
That is exactly what our Technology Fit Assessment is designed to produce. We run it as a vendor-neutral engagement — meaning we will tell you honestly if the answer is an off-the-shelf product, a modest configuration of something that already exists, or a bespoke build. Our interest is in giving you advice that is correct, not advice that leads to a project for us.
Before you commit to anything, let us help you think it through.
A structured half-day session with your management and technical teams. A comprehensive written report within five working days. Vendor-neutral advice on your best path forward — including honest counsel when the answer is not custom development. The R6,995 assessment fee is credited in full against your first development phase if you proceed with GEMIS.
Learn about the assessment →The conversation to have with any developer you are considering
If you do proceed to approach development companies, there are five questions worth putting to every one of them — not to catch them out, but because their answers will tell you a great deal about how they operate.
What do you need from us before you can write a proposal? A developer who can quote a project without first understanding your processes in detail is either quoting blind or building in a large contingency to cover what they do not know. Both are warning signs.
Who will actually be working on our project? The senior person who presents the pitch and the junior developer who writes the code are sometimes the same person. More often, they are not. You need to know who you are actually buying.
How do you handle scope changes? Scope will change. It always does. The question is not whether your developer accommodates changes, but how transparently they price them and how the process for approving them works. Ambiguity here is where projects become expensive.
What does ongoing support look like? A system that is built and handed over with no support arrangement is a liability. Understand what happens when something breaks, what the response time commitment is, and what the monthly or annual cost of that commitment is.
Can we talk to clients who have gone through a similar project? References are standard practice. Any development company with a genuine track record will be able to provide them. If the answer is evasive, treat it as a signal.
The investment in thinking before building is not glamorous. There are no visible deliverables, no progress milestones, and no satisfying moment when something goes live. But it is the work that determines whether the visible, milestone-tracked, go-live-celebrated project delivers what the organisation actually needed — or delivers something technically competent that nobody quite uses the way it was intended.
The organisations that get this right share a common characteristic: they were willing to slow down at the beginning in order to move faster later. They defined the problem before they specified the solution. They involved the people closest to the work. They were honest about their data and their budget. And they chose a development partner who would tell them difficult truths rather than one who would agree with everything they said.
That discipline, applied consistently, is the difference between software that lasts and software that gets replaced three years later by someone asking the same questions all over again.