Building a Cloud Business

Building the commercial stack
takes three years. This takes 90 days.


For funded teams, data centre operators, and new cloud entrants who need to go from infrastructure to paying customers — without engineering the commercial layer from scratch.

The hyperscaler era is over.
The specialist cloud era is here.

Enterprises no longer want everything from one hyperscaler. They want sovereign cloud, GPU compute, industry-specific compliance, regional latency. The market for specialist cloud providers has never been bigger — and the window to capture it is open right now.

🧠

GPU Cloud

AI training and inference capacity without Big Tech dependency. Enterprises paying a premium for sovereign GPU compute that doesn't move their data to a US jurisdiction.

🛡️

Sovereign Cloud

Data residency guarantees, national infrastructure, no US CLOUD Act exposure. Governments and regulated enterprises are actively looking for this.

🏥

Industry Cloud

Healthcare, fintech, defence — sectors that need a cloud built to their compliance requirements, not one where compliance is a feature tier they have to pay up for.

🏗️

Regional Cloud

Latency, local support, and regulatory proximity that hyperscalers cannot match at the regional level. A credible alternative for mid-market enterprises in underserved markets.

You have the ingredients.
The commercial stack is missing.

Most neocloud builders start strong on infrastructure. The gap is everything required to actually sell it — the layer between the hardware and the customer.

✓ What you have

✗ What's missing

Bare metal infrastructure

Owned, leased, or colocated. GPU nodes, compute nodes, storage. The hardware investment is made or in procurement.

Customer self-service portal

White-label, your brand. Customers provision their own resources without calling your team.

OpenShift platform

Chosen or contracted. A serious enterprise-grade Kubernetes platform as the foundation.

Service catalog + multi-tenancy

What you sell, publishable. Hard customer isolation so customers can't see each other's data.

Differentiation story

GPU, sovereign, industry-specific, regional. A reason to exist that hyperscalers can't easily replicate.

Usage metering + billing API

Per-customer resource tracking feeding your invoicing system. Without this, you can't charge accurately.

Funding + a timeline

Capital to build and operate. A runway measured in months, with investors expecting revenue before it ends.

Automated customer onboarding

Contract signed → workloads running in minutes. Not a manual provisioning process that doesn't scale.

Building it yourself
is a three-year detour.

Every neocloud that tries to build its own commercial stack discovers the same thing: the platform engineering problem is as hard as the infrastructure problem. And it takes just as long.

3 yrs

Engineering timeline

Multi-tenancy, portal, catalog, metering, billing integration, quota management, day-2 ops tooling. Each one is a project. In sequence, that's three years of build before launch.

€8M+

Engineering cost

Senior platform engineers building commodity cloud infrastructure instead of your differentiation. That's capital raised for competitive advantage — spent on solved problems.

0

Revenue while building

Every month of build is burn without revenue. Runway shortens. The competitive window narrows. Investors see traction metrics that aren't moving.

Late

Market entry

The GPU cloud, sovereign cloud, and regional cloud opportunities are being captured now — by teams that move fast. First-mover advantage in a specialist niche is real and it erodes.

The hyperscalers took a decade to build their commercial stack. You don't have a decade.

Before the platform,
answer what you're selling.

The most common neocloud failure mode isn't the technology — it's launching a catalog so broad it stands for nothing, or so narrow it can't grow. Service definition is the upstream problem that shapes everything downstream.

What kills neoclouds

✗ Trying to be a full hyperscaler on day one — 200 services before you have 10 customers. Complexity with no revenue to justify it.

✗ Building the platform before the catalog — engineering infrastructure for a service menu that changes after the first customer conversation.

✗ Pricing agreed after metering is built — the catalog item design depends on what you're charging for. Changing it later is expensive.

✗ Launching without an anchor customer — no design partner to pressure-test the portal and catalog before the public launch.

What we validate in week one

3–5 launch services — what you can sell, support, and meter from day one. Everything else is a roadmap item.

Pricing model — per vCPU, per GPU-hour, per namespace, flat-rate tier. Agreed before catalog design starts.

Target customer profile — who are the first 10 customers? What do they need? What SLA will you offer?

Anchor customer — one friendly design partner who will run real workloads and give real feedback before public launch.

Cloud Orchestrator is
the commercial stack — ready.

Everything required to run a cloud business as a product — not as a proof of concept. On top of your OpenShift. Under your brand. Serving your customers. In weeks.

Hard multi-tenancy

KCP virtual control planes per customer. Customers cannot see each other's resources, workloads, or network traffic — by architecture, not by network policy. Enterprise customers require this before signing.

White-label self-service portal

Your brand, your domain, your colour scheme. Customers log in and see your cloud — not Stakater's. They provision resources, manage teams, and view usage without contacting your operations team.

Service catalog engine

CRD-backed catalog items. Publish a new service — managed database, GPU node pool, object storage tier — the same day you decide to sell it. No integration project per new offering.

Metering + billing API

Per-customer usage tracked continuously. CPU, memory, GPU-hours, storage, egress — metered separately. Exported to your billing system via API. Invoicing automated from day one.

Automated customer onboarding

Contract signed → tenant workspace created → resources provisioned → customer in portal. Automated end-to-end. New customers don't trigger an operations ticket — they trigger a workflow.

Proven in production

Stakater Cloud — our own cloud product — runs exactly this operating model. Multi-tenant, self-service, white-label, metered, live since October 2024. We're not selling a vision. We're showing you what we run.

From infrastructure to paying customers

Validate what you're selling first. Then build it. First customer in 10 weeks.

1
Validate Week 1–2

Service catalog designed, pricing model agreed, anchor customer identified

We

· Catalog design workshop

· Pricing model validation

· Go-to-market scope

You

· Business model hypothesis

· Target customer profile

· Infrastructure inventory

2
Foundation Week 3–6

Cloud Orchestrator running, portal white-labelled, first tenant workspace live

We

· Deploy Cloud Orchestrator

· White-label portal with your brand

· First catalog items published

You

· OpenShift cluster ready

· Brand assets + domain

· SSO provider chosen

3
First Customer Week 7–10

Anchor customer running workloads, metering and billing live

We

· Anchor customer onboarding

· Billing API integration

· Metering validation

You

· Anchor customer signed

· Billing system ready

· Support workflow defined

4
Launch Month 3

Public launch, self-service signup, first 10 customers

We

· Self-service onboarding flow

· Launch readiness review

· Operations run-book

You

· Go-to-market comms

· Pricing published

· Support team trained

5
Scale Month 4+

New services added same day, new customer segments unlocked

We

· New catalog items

· Partner API integrations

· Quarterly growth reviews

You

· Customer pipeline

· New service demand

· Partner relationships

What separates neoclouds
that launch from ones that pivot.

The technical platform is the easy part. These four disciplines determine whether your cloud business reaches revenue — or spends its runway building the wrong thing.

Launch with 3–5 services. Not 50.

Pick the services your first 10 customers actually need. Build those well. Add more when you have customers requesting them. A focused catalog with great UX beats a sprawling one with rough edges. Hyperscalers win on breadth. Neoclouds win on depth.

Sign the anchor customer before you build

One friendly customer who will use the product while you're building it, give you feedback, and become your first case study. They shape the catalog. They validate the portal. They tell you what's missing before the public launch exposes it.

Pricing agreed before catalog design

What you charge for determines how the catalog item is built. Per-GPU-hour is metered differently to a flat-rate compute tier. Agree the pricing model in Validate — before Foundation starts. Changing it after the metering engine is configured is expensive.

Don't build what you can buy

Multi-tenancy, metering, the portal, the catalog engine — these are solved problems. Your differentiation is what you sell and who you sell it to. The engineering that matters is the product layer above Cloud Orchestrator — not the commercial infrastructure underneath it.

Your differentiation is what you sell.
Let us handle the rest.


Cloud Orchestrator gives you multi-tenancy, self-service, metering, and a service catalog —
white-labelled under your brand, serving your customers, in 10 weeks.


We run this ourselves. Stakater Cloud has been live since October 2024. The reference implementation is production — not a roadmap.

stakater.com