There is a question worth asking of any software development organisation: what proportion of your engineering time is spent building things that users directly benefit from, versus what proportion is spent on the infrastructure, tooling, and coordination that makes building possible?
For most teams, the honest answer is uncomfortable. A developer who spends 40% of their week on environment setup, pipeline debugging, access requests, dependency management, and deployment coordination is a developer who is spending 40% of their week not building product. Multiply that across a team of ten, and you have four full-time equivalents of engineering capacity disappearing into operational overhead every week.
Platform engineering is the discipline that addresses this directly. It is worth understanding precisely, because it is frequently confused with DevOps, with infrastructure management, and with the idea of simply having a good CI/CD pipeline.
What platform engineering actually is
Platform engineering is the practice of building and maintaining internal developer platforms — the curated set of capabilities, tools, and workflows that allow application developers to build, test, deploy, and run software without having to deeply understand or manage the underlying infrastructure.
The key concept is the "internal developer platform" (IDP) — not a single product but a coherent, opinionated set of capabilities that abstract away complexity without hiding it entirely. A well-designed IDP gives developers a self-service interface to the infrastructure they need: compute, databases, deployment pipelines, monitoring, secrets management, access controls. They get what they need, in a form that is consistent with organisational standards, without having to ticket the infrastructure team or configure anything from scratch.
This is different from DevOps in an important way. DevOps is a philosophy and a set of practices about how development and operations collaborate. Platform engineering is a specific implementation pattern — a dedicated team whose customers are other engineers, and whose product is developer experience. The two are complementary, but confusing them leads to organisations thinking they have solved the problem when they have only changed who does the operational work.
Why South African development teams feel this acutely
The platform engineering gap shows up in SA development contexts for a few specific reasons.
Small team dynamics. Most South African software companies and internal IT functions are operating with development teams of five to fifteen people. At this scale, it is genuinely difficult to justify a dedicated platform function — so platform responsibilities end up distributed, informally, across senior developers who could be building product. This is the path of least resistance and the most expensive outcome. Senior developers doing infrastructure work cost more than infrastructure specialists, and they are doing it at the expense of the output the business actually needs.
Cloud complexity without cloud expertise. The proliferation of managed cloud services — Azure, GCP, AWS — has expanded what is possible but also expanded what developers are expected to know. A developer who was effective in an on-premises environment is now expected to understand container orchestration, service mesh configuration, IAM policies, observability stacks, cost allocation, and whatever else the cloud estate requires. This is not a reasonable expectation for a developer hired to write application code. Without a platform layer, the knowledge gap becomes a constant source of delay.
Regulatory and compliance overhead. Financial services, health, public sector, and legal organisations in South Africa carry significant compliance requirements — POPIA, PCI-DSS, FSCA obligations, SARS requirements. Compliance controls need to be implemented consistently, and "consistently" in a development context means they need to be built into the platform, not left to individual developers to implement correctly every time. When compliance is not platformised, it is either a bottleneck (every deployment requires manual review) or a risk (developers implement it differently across services).
What a platform team actually does
A platform engineering team typically has three areas of responsibility.
The first is the developer experience layer: the tools, workflows, and abstractions that developers interact with directly. This includes CI/CD pipelines, self-service environment provisioning, internal service catalogues, documentation, and whatever tooling enables developers to go from code to deployed service quickly and safely.
The second is the infrastructure layer: the managed services, networking, security controls, and compute that sit underneath the developer experience layer. Platform engineers design this for consistency and repeatability, implement it as code, and manage its ongoing evolution as organisational requirements change.
The third is the operational layer: observability, alerting, incident response tooling, cost management, and capacity planning. Platform engineers ensure that when something goes wrong in production, the right information is available to the right people quickly.
What a platform team does not do — or should not do — is own specific application services. The moment a platform team becomes the bottleneck for application deployments, it has become an operations team with a different name. The measure of a successful platform team is how rarely application teams need to interact with them for routine work.
The business case
The ROI argument for platform investment is straightforward, though it requires discipline to make it properly.
Start with a time audit: ask your development team to track, for two weeks, how much time they spend on activities that are not writing application code. The number will be higher than you expect. Multiply it by your fully-loaded developer cost and you have the direct cost of your current platform gap.
Then estimate the throughput impact: if your team could ship features 30% faster — a conservative estimate for a team moving from an informal setup to a structured internal platform — what is the business value of that acceleration? In most organisations, it is significantly larger than the investment required to build and maintain a platform function.
The organisations that have made this investment consistently report the same outcomes: faster deployment frequency, fewer incidents, lower developer turnover (developer experience correlates strongly with retention), and faster onboarding for new engineers. None of these are surprising. They are the natural result of removing friction from the highest-leverage activity in a software organisation.
How to start without a dedicated team
If you do not have the scale to justify a dedicated platform team, the answer is not to do nothing. It is to be intentional about which platform investments have the highest leverage for your context.
In most small SA development organisations, the highest-leverage platform investments are: a standardised CI/CD pipeline that all services use (not one that each team configures from scratch); infrastructure-as-code templates that handle common patterns (web service, database-backed API, batch job) without custom configuration; and an internal runbook that documents how to do the ten things developers do most often.
These are not glamorous. They are also not optional if you want your team to be productive. The gap between having them and not having them is measured in hours per developer per week — and hours per developer per week, at South African developer salary rates, is a very tangible number.
CloudNala builds internal developer platforms for South African engineering organisations. If your team is spending more time on infrastructure than on product, let's talk about what that costs and how to fix it.