Four weeks, and you can stop after any of them
We do not run a sales process with a proposal at the end of it. We do real work on your real estate first, because it is the only honest way for either side to find out whether this will work.
About the free review- Step 1 · 30 minutes
A call with an engineer
Not a salesperson. We ask what you run and what is hurting. If we are not the right fit we say so on that call and suggest who might be — this happens perhaps one time in five.
- Step 2 · 10 business days
Well-Architected review
Free. Read-only access, six pillars, roughly six hours of your team's time. You receive the report and the remediation backlog regardless of what you decide next.
- Step 3 · 1 week
Remediation plan and quote
We agree what gets fixed now, what waits, and what you keep in house. The quote is based on the estate we have just spent ten days inside, not on a size band from a website form.
- Step 4
Decide
About a third of reviews end here, with the customer executing the plan themselves. That is a good outcome and we do not chase it.
Three weeks to pager transfer
We do not accept the pager until the runbooks exist. Taking on-call for a system you do not understand is how an MSP ends up escalating everything back to the customer at 2am — with an extra handoff in front of it.
This is why there is a 12-month minimum term
Onboarding is three weeks of senior engineering time delivered before the first invoice earns anything. The minimum term is how that gets funded, and we would rather explain it than hide it in a schedule.
- Week 0
Discovery
Read-only access, automated inventory, architecture walkthrough with your engineers, and a written scope boundary — what we operate, what you operate, and who decides when something falls between.
- Week 1
Alert hygiene
Every existing alert is fixed, deleted or given a runbook. On a typical estate this removes 60–70% of volume. It is the single biggest reason on-call stops hurting, and it happens before we take any responsibility.
- Week 2
Runbooks and access
Runbooks written jointly with your team and tested in non-production. Cross-account roles with external ID, MFA at our IdP, session logging into your CloudTrail.
- Week 3
Shadow, then transfer
We run alongside your roster for a week — same alerts, no responsibility — then take first-line paging. Your engineers become escalation rather than front line.
What working with us feels like month to month
Shared channel
Slack or Teams with our engineers in it. Questions get answered by the person who built the thing, usually in minutes.
Operations check-in
Thirty minutes. Open items, upcoming changes, capacity concerns, and anything approaching your included change capacity.
Service review
SLA performance, every incident and its cause, spend trend, risk register, and the next three things we recommend doing.
Review and DR test
Full Well-Architected review and a live disaster recovery exercise with a written, timed result. Semi-annual on Enterprise.
The monthly service review, specifically
This is the meeting that determines whether the relationship works. It is an hour, it has a fixed agenda, and it is attended by your lead engineer rather than only by an account manager.
- SLA performance against target, with any service credits already applied
- Every incident since the last review, with cause and what changed as a result
- Spend trend and variance, with the drivers named
- Risk register — what we are worried about that has not broken yet
- The next three recommendations, sized, with an owner
What we bring that you did not ask for
Every review includes at least one thing we think you should do that is not in scope and will not earn us anything — a licence you are over-paying for, a dependency that is a single point of failure, a team that is carrying too much.
If a service review only ever contains good news and upsells, the provider is managing the relationship rather than the platform.
Written down, because ambiguity causes bad nights
Most estates we join already have an internal platform team, an application development partner, a network provider, and sometimes an incumbent integrator mid-programme. That is normal.
What is not normal — and is the most common cause of a genuinely bad incident — is two parties each believing the other owns something. Every engagement starts with a written boundary document covering:
- Which systems we operate, and which we explicitly do not
- Who is first line for each, and who is escalation
- Who holds the change approval for each environment
- Who is on the bridge during a P1, and who makes the call when it cannot wait
- What happens when something falls between two parties — the default owner
A typical division
Because it sometimes does
A page describing an engagement model without this section is a brochure. Here is what happens when we get something wrong.
- Post-incident report within five business days of any P1 — cause, timeline, what we changed. Shared whether or not it flatters us.
- Service credits applied automatically where we miss a response target. You do not have to notice or claim them.
- Escalation to the Managing Director is available to you directly, and nobody here is measured on how rarely they get escalated to.
- If we caused an outage, we say so plainly in the report, in those words, rather than describing it as an environmental factor.
Our worst engagement
We accepted a migration deadline we should have pushed back on. The discovery phase was compressed from three weeks to nine days to fit a date that had already been announced.
We delivered. The customer's team paid for it in unpaid weekends, and two cutovers ran long because we found things during the migration that discovery would have found earlier.
We now decline compressed discovery. It has cost us at least two engagements since, and it is the right policy. We will talk about this in a first meeting if you ask, and you should ask any provider the same question.
How you leave, described before you join
Thirty days' notice after the initial term. No exit fee, no data extraction charge, no transition project you have to buy.
The handover is short because there is not much to hand over — your infrastructure code, pipelines, dashboards, runbooks and documentation have been in your repositories and accounts the entire time. That is deliberate, and it is the reason we can answer this question comfortably.
- Documented handover pack, current at all times rather than written at exit
- Credential and access rotation plan, executed with you
- Two walkthrough sessions with your incoming team or provider
- Thirty days of questions answered after the last day, at no charge
Why we make ourselves easy to replace
Partly principle. Mostly because it is what a serious customer's risk function will ask about — under APRA CPS 230 it is a formal requirement, and in any enterprise procurement it is question four or five.
An MSP that is hard to leave has built a commercial moat out of your operational risk. It works, right up until the day it is your problem.
The trade-off is real: we have less leverage at renewal than a provider who holds your Terraform. We think that is the correct side of the trade to be on.
Start with step one
Thirty minutes with an engineer. If we are not the right fit, we will say so on the call.