Discover, build, run. Each phase leaves you something you keep.

We map the system as it is, not as the documentation says it is. That means reading the code, watching the deploy, and talking to the people who get called when it breaks. The output is an architecture document, a risk register and a delivery plan, and it is yours whether or not you continue.

• System and dependency map, including the parts nobody documented
• Load profile measured against real peak, not assumed
• Risk register with likelihood, blast radius and mitigation effort
• A delivery plan with at least two options and an honest recommendation

Every increment ends with something installable or deployable, demoed to you, not to a project manager. Your engineers are in the repository from the first commit and review our pull requests. If your team cannot maintain what we are building, we are building the wrong thing.

• A walking skeleton to production in the first month — real pipeline, real signing
• Trunk-based development, short-lived branches, review on every change
• Test strategy agreed up front and enforced in CI, not aspirational
• Demo at the end of every increment, with what did not get done said plainly

We stay on the pager for what we build. Named response targets, a real rotation, monthly reporting including the months we miss our numbers, and a quarterly review of cloud spend and roadmap.

• Named SLOs tied to something the business recognises
• Runbooks written during the build, tested during handover
• A fixed share of each month spent reducing what woke us up most
• A handover plan agreed at the start of the engagement, not at the end

One decision-maker who can settle a question within two working days, access to the people who actually use the system, and a willingness to hear that the plan needs to change when the evidence says so. Projects fail on the first of those more often than on anything technical.