Most new digital initiatives in South Africa do not start on a blank page. They start inside something that already exists: a Microsoft 365 tenant, an Azure landing zone built for a previous programme, a CRM the sales team has used for years, an ERP that finance will not let go of, or an internal platform an engineering team built three restructures ago.
That is usually a good thing. Reusing what you already own is faster, it is often cheaper, and it avoids the procurement, security review and skills cost of introducing yet another product. When a CFO asks why the new citizen portal, broker app or field-service tool cannot simply run on the platform the organisation is already paying for, it is a fair question.
The problem is not reuse. The problem is that every platform arrives carrying decisions someone else made, for a different purpose, at a different time. If you build on top of it without noticing those decisions, they quietly become your decisions too.
Reuse is the right instinct
It is worth saying clearly that building on existing platforms is, in most cases, the correct default. South African organisations operate under real constraints. Budgets are set in rand while most platform licences are priced in dollars. Skilled engineers are scarce and expensive to retain. Public-sector entities face long procurement cycles, and private-sector firms face security and risk committees that have already approved a small number of technologies and are reluctant to approve more.
Against that backdrop, an existing platform carries a great deal of hidden value. The identity integration is already done. The security team already understands the controls. Licences may already be paid for under an enterprise agreement. There are people in the building who know how it behaves on a bad day. A new initiative that rides on these foundations can move from idea to something usable in weeks rather than quarters.
So the argument here is not "build something new". It is that reuse should be a deliberate architectural choice, made with your eyes open, rather than an inheritance you only discover the shape of once it starts to hurt.
Every platform is a set of decisions someone else made
A platform is not neutral infrastructure. It is a bundle of answers to questions that were asked before you arrived. Who are the users? How do they sign in? How reliably are they connected? Where does the data live, and who is allowed to see it? How does the cost grow when usage grows? Who fixes it when it breaks at eleven at night?
When the platform was first set up, those questions had sensible answers for its original purpose. A collaboration tenant assumes that users are employees with corporate identities, managed laptops and stable office connectivity. A CRM assumes that the people logging in are your own staff, licensed per seat. A landing zone built for an internal analytics programme assumes a certain data classification, a certain network topology and a certain tolerance for downtime. An internal developer platform assumes the deployment patterns and runtime choices of the team that built it.
None of those assumptions are wrong. They are simply specific. The trouble starts when a new initiative with different users, different data and different economics is placed on top of them, and nobody stops to ask whether the original answers still hold.
Where inherited assumptions bite in South Africa
The pattern shows up in very recognisable ways locally.
Consider a municipality that decides to extend its staff-facing Microsoft environment to support a residents' service request process. It is a reasonable idea, and the low-code tools make a first version easy to build. But the tenant was designed for a few thousand employees with organisational accounts. Residents do not have those accounts, many access services on prepaid mobile data rather than fibre, and a large share of them will use a low-end Android phone. Per-user licensing that made sense for staff becomes a very different number when the user base is a hundred thousand residents. The platform did not fail; the assumption about who the user is did.
Or consider a mid-sized insurer that extends its internal CRM to give independent brokers a self-service view of their policies. Suddenly the platform's assumption that every user is an employee collides with POPIA. Brokers are external operators, the data they see includes personal information about policyholders, and access needs to be scoped, logged and revocable in ways the original configuration never contemplated. The licence model also assumed internal headcount, not a broker network that may be ten times larger.
Infrastructure inherits assumptions too. A landing zone built for a back-office reporting workload may have been designed for a single region with modest availability targets, because a few hours of downtime during load-shedding-related network disruption was acceptable for overnight reports. Place a customer-facing payments or claims workload on that same foundation and the resilience assumption is no longer acceptable, but nobody revisited it because "the landing zone is already approved".
Even support models carry assumptions. A platform originally run by a large integrator under a managed-services contract may assume that partner will handle incidents. If the new initiative is delivered by a smaller local partner, perhaps chosen partly for B-BBEE reasons, the boundary of who supports what needs to be redrawn explicitly. Otherwise incidents fall into the gap between two contracts.
In each case, the platform was a sound choice. What went wrong was treating its existing configuration as a neutral starting point rather than a set of decisions that needed to be re-made for the new context.
Write the assumptions down before you build
The most practical defence is unglamorous: before committing to a platform for a new initiative, write down the assumptions that platform currently embodies, and then write down what the new initiative actually needs. Put them side by side.
This does not need to be a heavyweight document. A one or two page assumption register is usually enough, and it should cover a small number of dimensions. Who the users are and how they prove their identity. How they connect, on what devices, and how tolerant the experience must be of poor or intermittent connectivity. What data will flow through the system, how it is classified, and what POPIA and any sector regulation require of it. How cost scales, in rand, as usage grows, including the effect of exchange-rate movement on dollar-priced licences. What availability the business actually needs, and what happens during a regional outage or extended power disruption. And finally, who owns, operates and supports the solution once the project team has moved on.
For each dimension, the useful question is simple: does the platform's existing answer still hold for this new use? Where it does, you have confirmed that reuse is safe. Where it does not, you have found a design decision that would otherwise have surfaced as a production incident, an audit finding or an unpleasant licensing true-up.
This exercise also tends to change the conversation with sponsors. "We can build this on the existing platform" becomes "We can build this on the existing platform, provided we change three things, and here is what those changes cost". That is a much more honest basis for a funding decision.
Accept, adapt or isolate
Once the mismatches are visible, each one calls for one of three responses.
Some assumptions you can simply accept. If the new tool is for internal staff, on managed devices, handling data of the same classification as the existing platform, there is no reason to fight the platform's defaults. Accepting them is the cheapest path and should be the first one considered.
Other assumptions can be adapted through configuration or extension. External identity can often be added alongside organisational accounts. Conditional access policies, data loss prevention rules and audit logging can be tightened for a specific workload. A landing zone can be extended with a more resilient pattern for the workloads that need it, without re-architecting everything that does not. Adaptation is usually where most of the real design work lives, and it should be scoped and costed explicitly rather than absorbed as "configuration".
The remaining assumptions are ones you should isolate. These are the cases where the platform's model is fundamentally different from what the initiative needs, or where tying your business logic too tightly to the platform would create an expensive dependency later. Here the sensible move is to keep the platform for what it is good at, and place a thin, well-defined boundary between it and the parts of your solution that need to behave differently. A residents' service might use the existing platform for internal case management while exposing a lightweight, mobile-friendly front end built for low-bandwidth access and priced on consumption rather than seats. The platform is still reused, but its assumptions stop at a boundary you control.
Isolation also matters for exit. Platforms change their pricing, retire features and get replaced in procurement cycles. If your core rules, data model and integration contracts live inside platform-specific features, moving later becomes a rebuild. If they sit behind a boundary you own, the platform becomes a replaceable component rather than a permanent landlord.
What good looks like six months later
The difference between inherited and deliberate reuse becomes obvious a few months after go-live.
When assumptions were inherited without examination, the symptoms are familiar. Licence costs grow faster than adoption, because the pricing model was built for a different user base. Security and privacy teams raise findings about external users or data flows that the original design never anticipated. Users on mobile data complain that the experience is slow or unusable. Incidents bounce between the platform owner and the delivery partner because nobody defined the support boundary. And the team starts to say that "the platform is the problem", when the platform was actually doing exactly what it was set up to do.
When reuse was deliberate, the picture is quieter. The business case reflected the real cost in rand, including the adaptations. Privacy and security controls were designed for the actual users and data. The parts of the solution that needed to behave differently were isolated, so the platform team is not being asked to bend their environment for one workload. Support responsibilities are written down. And because the assumptions were recorded, the next initiative that wants to reuse the same platform can start from a much better-informed place.
That last point is where the real long-term value sits. An organisation that habitually records what its platforms assume, and checks new initiatives against those assumptions, steadily builds a platform estate that is understood rather than merely occupied. Reuse becomes a strategic advantage instead of a source of slow-burning surprises.
Building on what you already have remains one of the most sensible decisions a South African organisation can make. The discipline is simply to treat the platform as a starting point you have chosen, not a set of conditions you have silently agreed to.
How CloudNala can help
We help organisations assess the platforms they already own, write down the assumptions those platforms carry, and design new initiatives that reuse what works without inheriting what does not. If you are about to build something new on an existing platform, the assumption register is a good first conversation.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Request a Cloud Review or write to us at consult@cloudnala.co.za