Cloud structure, access, delivery and operations as one workable baseline: built in days from sound decisions, so it keeps working.
Platform in a Week is not an advisory deck and not an open-ended consulting track. It is a bounded build sprint for the platform layer teams can continue shipping on.
Not because everything fits, but because the right first baseline is chosen sharply. Accounts, rights, DNS, approvals and topology need to be ready in advance. If access or decisions slip, the schedule slips with them.
Cloud, CI/CD platform, cluster model and constraints are confirmed in the days or weeks beforehand.
Cloud structure, access paths and technical starting points are confirmed and turned into the first usable baseline.
Landing zone, networking, identity boundaries and the Kubernetes baseline are put in place with IaC first.
CI/CD, GitOps, logging, metrics and alert routing are wired into the chosen stack.
The baseline is tested, documented and handed over with a clear list of follow-on work.
| Scenario | Good fit for |
|---|---|
| Single-cluster | Teams that need a compact production baseline quickly and want limited operational complexity. |
| Multi-cluster | Environments where platform components and workloads should be separated deliberately. |
| AWS foundation | Companies that want AWS to be the foundation of their cloud and want that foundation set up cleanly, scalably and without rework later. |
| Azure foundation | Companies that want Azure to be the foundation of their cloud and want subscriptions, identity and platform structure organised properly from day one. |
Scope, cloud structure, platform layer, access and delivery as the first usable baseline.
Maintenance, response and team questions placed in fixed coverage after go-live.
JIT Access, FinOps, automation or delivery acceleration for a missing feature or optimisation.
For teams that need one serious production baseline without immediately introducing a separate shared services layer or multiple runtime clusters.
Repos, CI/CD, GitOps and IaC move through one controlled change path.
One workload cluster with networking, ingress, secrets, storage and the cloud components around it.
Observability, alerts, documentation and handover are set up for normal daily operations.
One management path for repositories, CI/CD, GitOps and IaC, plus one cluster baseline with networking, secrets, storage, observability and clean handover. That makes this shape a strong fit when speed matters more than heavy operational separation.
For environments where platform control, shared services and runtime workloads should be split deliberately from the start.
Source, CI/CD, policies and promotion are controlled from one central layer.
Argo CD, Grafana, Thanos, Loki and Tempo support the cluster fleet as a whole.
OTA and production stay deliberately separate, with scoped access and clear ownership.
The management layer drives promotion and policy, shared services centralise observability and cluster control, and OTA or production stay separate as their own workload networks. That gives more control, but it also adds structural complexity.
The output is not an advisory deck. It is a usable platform baseline with captured choices, working paths and clear next steps.
Platform scope, defaults and technical boundaries are captured.
Cloud structure, runtime and guardrails stand as a usable base.
CI/CD or GitOps makes changes reviewable and repeatable.
Access, secrets, logging and signals are included from the base.
There is a transferable plan for support or targeted improvement.
In one conversation we map the current platform friction, constraints and logical first step. If the full baseline still feels too large, a Platform Scan first makes clear what is genuinely needed now.