Most large technology failures are not caused by bad code. They are caused by decisions made early, when the solution was still a set of slides and everyone was optimistic. By the time the cost of those decisions becomes visible — in the run bill, the rework, the integration that was never scoped — the people who made them have often moved on, and the organisation is left paying interest on a mistake it cannot easily unwind.
Solution architecture is where those decisions get locked in. Done well, it is quiet and unglamorous. Done poorly, it produces systems that technically work but cost far more than they should to build, run, and change. Across South African banks, insurers, retailers, telcos, and public sector programmes, the same mistakes recur with remarkable consistency. Here are the seven that cost the most.
What makes these mistakes expensive is not that they are subtle. Most of them are obvious when named. It is the delay — the decision costs nothing to change in the week it is made, and a great deal to change by the time anyone can see what it did.
Designing for a steady state that does not exist
The first mistake is architecting for the world as the deck describes it rather than the world the system will actually live in. Reference architectures assume reliable power, predictable connectivity, and clean inputs. South African operating conditions offer none of those reliably.
Load-shedding is the obvious example, and it is still routinely under-designed for. An architecture that assumes always-on connectivity between a branch, a warehouse, or a clinic and a central cloud region will degrade the moment the power schedule bites. The right response is not always expensive redundancy — sometimes it is a design that degrades gracefully, queues transactions locally, and reconciles when the link returns. But that behaviour has to be designed in deliberately. Retrofitting resilience after go-live, once the failure mode has already embarrassed the business, costs several times more than building for intermittency from the start.
The same applies to load itself. Systems architected around average demand fall over at month-end, at grant-payment dates, at the exact moments they matter most. The steady state is a fiction. Architecture has to account for the peaks and the outages, because those are where the money and the reputation are actually lost.
Confusing the diagram with the architecture
A neat diagram is not an architecture. It is a picture of one. The architecture is the set of decisions behind the diagram — why this datastore and not that one, why this boundary sits here, what was traded away to get the deadline, and under what conditions the decision should be revisited.
When those decisions are never written down, the organisation loses the reasoning the moment the architect rolls off. New team members inherit boxes and arrows with no record of intent, so they either preserve constraints that no longer apply or unknowingly violate ones that still matter. Both are expensive. The discipline that prevents this is mundane — a short architecture decision record for each significant choice, capturing the context, the options, the decision, and the consequences. It takes an afternoon. Skipping it is one of the cheapest mistakes to avoid and one of the most common to make.
Treating non-functional requirements as an afterthought
Functional requirements get the attention because they are easy to demo. The system captures the claim, generates the invoice, shows the dashboard. Non-functional requirements — security, performance, data residency, auditability, recoverability — get waved through with a line that says "must be secure and scalable," and then they quietly determine whether the whole thing survives contact with production.
In South Africa this is not optional detail. POPIA imposes real obligations on how personal information is stored, processed, and moved, and certain data cannot leave the country's borders without consequences. An architecture that decides where data lives only after the build has started is an architecture that will be reworked, because data residency and the lawful basis for processing are structural choices, not configuration settings. The same is true for sector rules in financial services and health. Bolting compliance on at the end is how a nine-month project becomes an eighteen-month one, and the difference is paid in professional fees and delayed revenue.
Performance and recoverability deserve the same early treatment. "How quickly must this recover, and how much data can we afford to lose?" is a business question with a direct cost attached. Answering it after the platform is chosen means either overpaying for resilience nobody asked for or discovering, during an incident, that the resilience everyone assumed was never there.
Buying the vendor's architecture wholesale
Cloud providers and product vendors publish excellent reference architectures. They are also built for a hypothetical global enterprise with hyperscale traffic, a large platform team, and budgets denominated in dollars. Adopting one wholesale, without asking which parts your organisation actually needs, is a reliable way to overspend.
The cost lands twice. First in the build, where you provision multi-region, multi-service complexity for a workload that serves a few thousand South African users. Then in the run, where every one of those services bills monthly in USD or EUR, and the rand-denominated invoice climbs every time the currency weakens — with no change in what the business is getting. An architecture that is right for a US retailer at continental scale can be actively wrong for a Johannesburg insurer, not because it is bad, but because it solves a problem you do not have at a price you should not pay.
The discipline here is subtraction. Start from the outcome and the constraints, then take the reference architecture apart and keep only what earns its place. Lean architecture is not incomplete architecture — it is architecture that has been made to justify every component it carries.
Underestimating integration
Ask a project team where the risk is, and they will point at the shiny new component. The risk is almost never there. It is in the integration — the twelve other systems the new solution has to talk to, most of them older than the project sponsor's tenure, few of them documented, none of them designed to be integrated with in the way you now need.
Integration is usually the real MVP, and it is routinely scoped as an afterthought. A core banking platform, a policy administration system, a municipal billing engine, an identity provider, a payments gateway — each has its own quirks, its own owners, and its own change calendar. The effort to reconcile them, handle their failures, and keep them consistent frequently exceeds the effort to build the new capability itself. Architectures that treat integration as a line item rather than a first-class concern produce estimates that are wrong by multiples, and the overrun shows up exactly when the project can least absorb it.
Naming the integration surface early, mapping the systems and their owners, and designing explicitly for partial failure between them is not glamorous work. It is the work that determines whether the delivery date is real.
Designing a system nobody can run
An architecture is a promise about operations, and someone has to keep that promise after the launch party. The mistake is designing for the build team's capabilities rather than the run team's. A sophisticated, service-heavy platform handed to a small operations group with none of the relevant skills becomes fragile the day the delivery partner leaves.
This matters more in the South African market, where specialised cloud and platform skills are genuinely scarce and expensive to retain. An architecture that quietly assumes a large, senior platform team is an architecture that assumes a cost structure and a hiring pipeline the organisation may not have. The right questions belong in the design phase, not the handover meeting: who operates this, what skills do they have, how do they patch it, how do they know when it is unhealthy, and what happens when the person who understands it best resigns. Where the answers are thin, the architecture should be simpler — deliberately trading some elegance for something the client can actually own.
For public sector programmes, the same logic extends to the operating model. A citizen service is not a website; it is a service that has to be staffed, funded, and supported for years. Architecture that ignores who supports the solution after the workshop is architecture that produces launches, not services.
Optimising for build cost instead of total cost
The final mistake ties the others together. Enterprises consistently make architecture decisions to minimise the cost of building, and then pay for that saving many times over across the life of the system. The cheapest thing to build is often the most expensive thing to run, to change, and eventually to replace.
Total cost of ownership includes the monthly cloud bill in rand terms, the effort to make routine changes, the cost of the skills required to operate it, the licensing that scales with use, and the eventual cost of getting off it. A committed cloud discount signed against an inefficient first-year baseline locks in that inefficiency for years. A build that skips automation to hit a date creates manual toil that compounds every month afterward. These are not technical details. They are the difference between a system that becomes a quiet asset and one that becomes a line item the CFO learns to dread.
None of these seven mistakes is exotic. They are the predictable result of letting delivery pressure, vendor defaults, and optimism substitute for a small amount of deliberate thinking early on. The organisations that avoid them are not the ones with the most sophisticated technology. They are the ones that treated architecture as a set of consequential decisions to be reasoned about and written down — before the diagram was drawn, and long before the invoice arrived.
How CloudNala can help
We run solution and cloud architecture reviews for South African enterprises, financial services and public-sector organisations — usually either before a major build commits to a shape, or after an existing one has started costing more than anyone expected. The work is deliberately early and deliberately blunt: name the decisions that are about to become expensive, quantify what they will cost over the life of the system rather than the length of the project, and write them down while they are still cheap to change.
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