Stationed / Method

The deployment loop

Five steps, run in order, repeatedly. Most of what makes a deployment succeed is decided in the unglamorous parts — which workflow we pick first, what we refuse to build, and where we deliberately keep a human. This page is the whole method, including the parts that cost us money.

Stationed method in context

A methodology is only useful if it tells you what to do when something goes wrong. So this isn't a diagram of a happy path. Each step below includes the decision we actually have to make, the way that decision usually goes wrong, and the thing we do differently because of it.

The loop runs at two speeds. Inside a single deployment it takes days to weeks. Across an engagement it runs continuously, because each Prove tells us where the next Embed should point.

01

Embed

What happens

We sit with the people doing the job — not their manager, not a process document — and watch the actual workflow. The copy-paste. The double-check. The thing everyone does manually on Fridays. The spreadsheet that is secretly the system of record.

The decision

which workflow to attack first. This is the highest-leverage decision in the entire engagement and it is usually made for the wrong reason.

How it goes wrong

the first workflow gets chosen because it's the most visible, or because an executive named it in a meeting. Visible and tractable are different properties. A deployment that targets a prestigious workflow with fuzzy success criteria produces a demo; a deployment that targets a high-frequency workflow with an obvious right answer produces a system people fight to keep.

What we do about it

we rank candidates on four things and write the ranking down — frequency (how many times a week does this happen), pain (does the person doing it volunteer a complaint unprompted), tractability (is there a defensible right answer, or is it taste), and ownership (is there one person whose job gets easier). Anything that scores badly on ownership gets deprioritized regardless of how good it looks.

What you get from this step

a ranked list of opportunities with an argument for the order, and an explicit statement of what we're not doing first and why.

02

Build

What happens

We build the smallest version that is actually useful to one real person doing real work — in your environment, against your data, not a sanitized extract.

The decision

what to leave out. Scope discipline here is the difference between learning something in a week and learning nothing in a quarter.

How it goes wrong

the build grows a settings page, an admin panel, and a dashboard before anyone has confirmed the core action is worth automating. Every one of those is a reasonable request. Together they delay the only thing that produces information, which is a person using it.

What we do about it

the first version handles the common case end to end and refuses the rest loudly. No silent degradation — if the system can't handle an input, it says so and hands it back. We would rather ship something that covers 70% of cases and is honest about the other 30% than something that covers 95% and lies about the remaining 5%.

On agents specifically

our engineers work by directing fleets of coding agents, which changes what the bottleneck is. Generating an implementation is cheap. Deciding what should exist, reviewing what came back, and owning it in production is the job. That's also why we interview the way we do.

What you get from this step

a working system in your environment, with its limits written down.

03

Land

What happens

The system moves into the workflow people already use — their inbox, their CRM, their spreadsheet, the tool that's already open — and someone stops doing the old thing.

The decision

where the human stays. Not everything should be automated even when it can be.

How it goes wrong

this step gets treated as rollout — a training session, a Loom, an announcement in Slack — when it's actually the hardest engineering in the whole loop. Permissions models, rate limits, four date formats in one text field, the record that has a trailing space, the approval that exists for a legal reason nobody documented.

What we do about it

we keep the human at the expensive decision and automate everything either side of it. The test we apply: if this output is wrong next Tuesday, what does it cost, and who finds out? Cheap-and-visible gets automated. Expensive-and-silent keeps a human, and we design the review step to be fast rather than removing it. Trust is a design constraint — show sources, make the failure mode boring, never make someone guess whether the system ran.

What you get from this step

the system running inside the existing workflow, with a defined review step and a defined failure behavior.

04

Prove

What happens

We compare against the baseline we agreed on before the build started, and we decide.

The decision

whether to expand it or kill it.

How it goes wrong

nobody wrote down the baseline, so success becomes a matter of opinion — and the loudest opinion belongs to whoever was skeptical first. Or the metric gets chosen after the results arrive, which everyone can smell.

What we do about it

the number gets agreed before we build, in one sentence, along with how we'll measure it and who reads it. We would rather commit to an uncomfortable number than a safe one, because a safe number doesn't survive contact with a CFO. And we kill things. A deployment that didn't move its number gets turned off and written up — what we expected, what happened, what it tells us about where to point next. That write-up is usually worth more than the build was.

What you get from this step

the measured result, and a decision with a reason attached.

05

Transfer

What happens

Your engineers take ownership. Documentation, walkthroughs, and time spent in the code together until they can extend it without us.

The decision

when we're actually done.

How it goes wrong

transfer is scheduled as a final phase, so it becomes a handover document nobody reads and a dependency that quietly persists. The consultant's incentive runs the other way here, which is exactly why it has to be structural rather than good intentions.

What we do about it

transfer starts at step 02, not step 05. Your engineers are in the repo while it's being built, the system uses your stack rather than ours wherever there's a choice, and the test for done is behavioral — your team ships a change to the system without us in the room. Not a walkthrough. A merged change.

What you get from this step

ownership. Code, documentation, and a team that has already modified it once.

The deployment loop

Then the loop runs again.

The result of Prove is the input to the next Embed. A deployment that worked tells us which adjacent workflow to look at; one that didn't tells us something more useful about where the constraint actually lives. This is why engagements expand from the inside rather than from a roadmap — the second deployment is chosen with information the first one produced.

Bring us a workflow, not an RFP.