Every organisation that decides to run a cloud reaches the same fork early. Build the platform yourself, or start from one that already exists.
Building looks reasonable on a whiteboard. Deploy the infrastructure, hire a few engineers, put a portal on top, launch some services. The hardware has a quote. The team has a headcount. The plan fits on one slide.
What the slide rarely shows is that a cloud platform is not an infrastructure project. It is a software business, and it never ships its last release.
Customers are not buying virtual machines
The first underestimate is scope. A new cloud is judged against what its customers already use elsewhere: self-service provisioning, compute, object storage, Kubernetes, managed databases, security services, monitoring, backup and disaster recovery, an API for everything and an invoice that makes sense. Multi-tenancy underneath all of it. A marketplace on top.
Virtual machines are the entry ticket. Everything after them is what a customer actually compares.
What “build” actually means
Say “build a cloud” and most teams picture the bottom layer. A cloud that can be sold needs six:
- Infrastructure — compute clusters, storage, networking, security systems and a high-availability design.
- Cloud management — provisioning, orchestration, policy and automation.
- Customer experience — a self-service portal, a service catalogue, user management and role-based access.
- Commercial — metering, subscriptions, billing and chargeback.
- Ecosystem — a marketplace, partner onboarding and service integrations.
- Operations — monitoring, logging, capacity planning and lifecycle management.
Hardware lives in the first layer. The other five are software, and each one needs a team to build it and a team to keep it current.
The costs that are not on the quote
Infrastructure is usually the first number in a build business case. It is often the smallest part of the real one.
People. Cloud architecture, software development, networking, security, automation and platform engineering, all at once, and all in demand everywhere else. Recruiting them is hard. Keeping them is harder.
Continuous development. A cloud is never finished. Customers expect new services, new integrations, security fixes and performance work every quarter. The platform becomes a product roadmap you own for good.
Security and compliance. Vulnerability management, monitoring, incident response and the evidence an auditor will ask for, designed into every layer rather than added at the end.
Support. The moment a customer runs on your platform, you owe them documentation, training, service management and someone to call.
The clock is the biggest cost
A realistic internal build, phase by phase, looks like this:
- Architecture and planning: 3–6 months
- Development and integration: 6–12 months
- Testing and validation: 3–6 months
- Commercial readiness: 3–6 months
That is 12 to 24 months before the first invoice, and sometimes longer. Deploying a platform that already exists works on a different scale: infrastructure, platform configuration, commercial setup and first customer onboarding, with the cloud launched in 90 days.
A late launch does not only cost more. It earns later.
The development budget is visible. The opportunity cost is not. Every month spent building is a month without customers, subscriptions, marketplace sales or partners, while competitors sign the accounts you were planning to win and the technology you started with moves on. For national cloud programmes, telecom operators and regulated industries, where demand for sovereign cloud and AI infrastructure is arriving now, the gap matters even more.
Why internal builds stall
Build programmes rarely fail outright. They slow down, for familiar reasons. Scope grows as each new requirement surfaces. Engineers are pulled onto other priorities. A specialist skill turns out to be unavailable. The technology moves faster than the plan.
And the hardest discovery comes last. Building the technology was the easier part. Building a cloud business around it, with pricing, sales, partners and support, is a second project nobody budgeted for.
The trade hiding inside the question
Build versus buy is usually framed as control against speed. Build, and it is yours but late. Buy, and it is fast but someone else’s. That framing rests on the assumption the whole industry runs on: that a real cloud takes capital only a handful of global companies can raise, so everyone else must choose between a cloud that works and a cloud that is theirs.
It helps to separate two things the framing blends together. Owning the platform’s code is one kind of control. Owning the customers, the prices, the data, the operations and the brand is another, and it is the one that decides whether you have a business. A platform you license can leave all of the second kind with you. A reseller agreement cannot.
When building does make sense
There are honest cases for building: genuinely unique operational requirements, specialised services no platform offers, or an organisation that already runs large-scale platform engineering as a core skill. They exist. They are the minority.
For most operators, the value lies elsewhere: customer relationships, industry knowledge, regulatory expertise, local support and service delivery. Customers choose a cloud for its reliability, its security, its support and the services it offers. They do not choose it for how the portal was written.
Buy the platform. Keep the business.
That is the case Oasis Stack is built to make. It runs above infrastructure you already own (CloudStack, OpenStack, VMware, Kubernetes, bare metal or GPU, on-premises or in a colocation facility you choose) and publishes it as services, with no lock-in to any infrastructure vendor. Tenancy, the customer lifecycle, billing, governance and a marketplace are already there, which is why a cloud launches in 90 days rather than two years.
The ownership stays where it counts: your brand, your customers, your prices and your invoices. The platform is a flat fee per deployment, banded by scale, so it takes no share of what you build on it. You choose whether to run it yourself or have the Oasis Stack team operate it for you. And CloudHost runs its own public cloud, YallaCloud, on six Oasis Stack modules in production.
The real question
The question was never whether you could build a cloud platform. Given enough time and engineers, many organisations could. The question is whether building it yourself creates more value than launching, selling and growing a cloud business this year.
Engineers can be hired and hardware can be bought. The months spent building cannot be bought back.