Movaro Forward deployed engineering
Taking one engagement
Movaro, independent practice

The work is under NDA. The thinking isn't.

I embed with enterprise teams, find what is actually broken, and stay until it is fixed. Most of it I can never show you. This page is the part I can.

Start a conversation No deck, no calendar link. One line is enough.
02 Method

What I notice first.

Every engagement runs the same eight stages, and each one has to be cleared before the next. The ring below is held in place while you scroll: one stage per step, starting again at Qualify.

03 The loop
01
QUALIFY
Is this worth deploying for?

The eight stages

  1. A one page engagement note: the problem, the sponsor by name, the access required, the decision this work would change, and the conditions under which I stop.

    Gate A named sponsor, access granted, and a decision that could actually go the other way. If any of the three is missing, there is no engagement yet.

  2. Three artefacts: a workflow map of what the team actually does, including the workarounds; a data inventory (what exists, where it lives, its quality, who can read it); and a cause memo with the evidence for the cause.

    Gate The cause is written and the client either agrees or names the disagreement. The data inventory is the first engineering deliverable, and it often proves the system needs to be smaller or aimed elsewhere.

  3. A scope note: the smallest slice that proves something, what is explicitly out, the constraints and operating limits, and the number that will judge the work with how it is measured.

    Gate The measure is agreed before anything is built. If it cannot be measured, the engagement is stopped here rather than at the end.

  4. A thin slice running end to end on real data: the interface contract (schema and API), the workflow it supports, and prototype notes recording its limitations.

    Gate Someone can react to something specific, not to a requirements document.

  5. An integration map (systems, identity, permissions, data boundaries), a deployment and rollback procedure, and the access model.

    Gate It runs inside the client's environment under their controls, and a failed dependency can be rolled back.

  6. Monitoring and alerting, an incident guide, a known limitations list, and evidence from real use: who adopted it and what the system actually did.

    Gate Real users in the real workflow, with blast radius deliberately bounded.

  7. The handover pack: architecture and dependency records, runbooks, the support path, unresolved risks, training, a completed reverse shadow, and written acceptance.

    Gate A client engineer has run the deployment and the uncomfortable edges unaided, and the receiving team has accepted it in writing.

  8. A pattern note: what becomes a template, an evaluation harness, a runbook or a warning for the next time, separated from what stays specific to this client.

    Gate The next engagement starts from a written position, not from recall.

04 What gets built

What gets built

Seven kinds of artefact, not seven products. Each one is something the client's team can run without me.

  1. Interfaces

    The screens a person actually uses.

  2. Services

    The work that runs without a screen.

  3. Data models

    What the business means, written down once.

  4. Enterprise integrations

    Joins to systems you cannot replace.

  5. Evaluation harnesses

    Proof the thing still works next month.

  6. Deployment pipelines

    Shipping without a hero on standby.

  7. Runbooks

    The instructions for the bad night.

I take one engagement at a time. If you have a problem worth diagnosing, I would like to hear it described plainly.

I want the problem, not the pitch.

I read everything myself, and I take one engagement at a time. The work stays under NDA; the problem does not have to.

or write to mike@movaro.co.uk

You can write to that address directly instead.