Platform in a Week
Make the baseline hold up: scope, cloud structure, platform layer, access and delivery.
Offer
From loose service to the right platform step.
The route is intentionally simple: first make the platform baseline hold up, then organise continuity, then add or optimise what is still missing.
Support Subscription
Place maintenance, response, team questions and small improvements in fixed coverage.
Specialist modules
Add a missing feature or optimisation: access, cost, automation or delivery.
The platform route
Platform in a Week builds the baseline. Support places maintenance and response in fixed coverage. JIT Access, FinOps, Automation and Delivery Acceleration improve one layer when it needs focused attention.
Step 1
Platform in a Week: make the baseline hold up.
A production-ready platform baseline in 7 working days, with preparation up front and clear scope.
7 working days.
after clear preparation.
The week works because scope, access and decision-making are clear up front.
- Beforehand
Intake and scope freeze
Lock cloud, CI/CD platform, cluster model and preconditions in the days or weeks before the delivery week.
- Day 1
Foundation and constraints
Confirm cloud structure, access paths and technical starting points so the build can start with focus.
- Days 2-3
Foundation and runtime
Landing zone, networking, identity boundaries and Kubernetes or runtime baseline as IaC.
- Days 4-5
Delivery and observability
Wire CI/CD, GitOps, logging, metrics and alerts into the stack.
- Days 6-7
Validation and handover
Test, document, capture decisions and define the sensible next steps.
Usually delivered over roughly two calendar weeks, depending on calendars, access and decisions.
Scope
Sharp scope is why a week works.
In scope
What you get
- Cloud structure, networking and identity boundaries
- Runtime or Kubernetes baseline within the agreed stack
- CI/CD or GitOps with access and observability as a baseline
- Documentation and choices that remain explainable after handover
Out of scope
Not this sprint
- Application migrations or workload rebuilds
- Open custom integrations outside the agreed baseline
- Extensive training or enablement programmes
- Ongoing operations without a separate support agreement
After go-live
What is in place afterwards?
- 01
Scope and choices
Platform scope, defaults and technical boundaries are captured.
- 02
Cloud/runtime base
Cloud structure, runtime and guardrails are in place as a usable baseline.
- 03
Delivery path
CI/CD or GitOps makes changes reviewable and repeatable.
- 04
Access and observability
Access, secrets, logging and signals are built into the baseline.
- 05
Next route
There is a transferable plan for support or targeted improvement.
Step 2
Support Subscription: keep it working.
Support is not a loose helpdesk. It is fixed platform and delivery coverage to keep the baseline healthy, explainable and usable.
Maintain
Keep it healthy
Updates, checks, drift prevention and healthy baseline configuration.
Support teams
Help teams use it
Resolve questions around pipelines, deployments, access and operational signals faster.
Improve
Improve the platform
Small improvements and pattern corrections before ad-hoc becomes normal again.
How support relates to Platform in a Week
Platform in a Week builds the baseline. Support covers continuity, response, maintenance, team questions and small improvements. Larger extensions remain separate scope.
Outside support
- Large redesigns or new platform modules
- Application work and workload migrations
- Unbounded project execution inside a monthly subscription
Level 1
Platform Maintenance
For teams that use the platform themselves but want structural maintenance handled properly.
- Updates, patching and periodic platform checks
- Keep infrastructure stable and prevent configuration drift
- Small corrections on access, observability and cluster defaults
Best fit when calm, maintenance and predictable platform ownership are the main need.
Level 2
Monitoring & Response
For teams that also want someone to respond once the platform starts showing signs of instability.
- Everything in Level 1
- Respond to alerts, resource pressure and signals that the platform is becoming unstable
- Investigate issues around clusters, ingress, load balancers, WAF, networking or observability
Best fit when the team builds itself, but should not carry every operational signal alone.
Level 3
Full DevOps Support
For teams that need help with real delivery issues in practice on top of platform coverage.
- Everything in Level 2
- Support on CI/CD incidents, build failures and deployment problems
- Developer support on pipelines, release flow and delivery debugging
Best fit when platform and delivery become the bottleneck together.
Step 3
Specialist modules: add or optimise what is missing.
These modules sit next to or on top of the baseline. Scope follows the concrete platform problem.
JIT Production Access
Temporary production access with scope, approval, audit trail and automatic revocation.
EffectProduction access without permanent privileges.
FinOps
Visibility, reporting and automation around cloud cost that is currently hard to explain.
EffectMore control over spend and less waste.
Custom Automation
Automate platform workflows where manual work hurts speed or reliability.
EffectLess operational friction.
Delivery Acceleration
Improve CI/CD, release flow and deployment reliability on existing platforms.
EffectMore predictable delivery with fewer exceptions.
Which first step fits the platform?
In one conversation we separate building the baseline, keeping it healthy and improving a specific layer. That keeps the first scope sharp.
Plan a platform scan