Five practices, one operating model.
These problems rarely arrive alone — one usually turns out to be attached to two others. The practices are separately scoped and separately priced, but they share the same engineers, the same monitoring, and the same conventions, so the seams between them don't leak.
- engagements start at
- 2-week assessment
- delivery
- 2-week increments
- artifacts
- Your repository
What each practice takes on.
Read the one that matches the problem in front of you. Each page covers scope, how the engagement runs, a worked example, and the questions clients ask before signing.
The four things that don't change between practices.
A firm that does five things badly is worse than a firm that does one well. These are the commitments that make the five defensible.
A fixed-scope assessment first
Every practice opens the same way: a short, fixed-fee engagement that produces a written account of what you run and a costed plan. You own the document whether or not you continue.
The same engineers through delivery
The people who write the assessment are the people who do the build and the people who take the escalation. There is no handover to a delivery team that has never read the report.
Artifacts in your repository
Infrastructure code, runbooks, decision records, and test suites live in your version control from the first commit. Leaving us should be a decision, not an extraction.
Increments you can stop at
Work lands in slices that each end with something running. If budget freezes or priorities move, you stop at a boundary rather than mid-cutover.
Start from the sentence that sounds most like your week.
Nobody arrives asking for a landing zone. They arrive because something is costing them time, money, or sleep. These five are what the practices were built around.
Not sure which practice you need? Neither are most people.
The assessment is deliberately practice-agnostic. We look at what you run, tell you where the risk and the cost actually sit, and you decide what to do about it.