Three ways to work together.

1. 01

   Discovery

   A short, paid engagement that turns "we think we need X" into a plan you could hand to any competent engineer.

   Assessment — scheduling system

   Prepared over eight working days · yours to keep

   1. What we found

   Risk	What it costs	What we’d do
   One engineer holds the deployment path	Blocks every release	Document it, then automate the two manual steps
   The integration retries without an idempotency key	Duplicate orders under load	Key on the upstream reference before adding capacity
   No staging environment matches production	Every release is the first test	One environment parity fix, ahead of the feature work

   2. Routes forward

   • AFix the release path first. Six weeks, lowest risk.
   • BShip the feature on the current path, accept the release cost.
   • CRewrite. Costed here so it can be ruled out on numbers.

   3. Recommendation

   Route A, with a scoped estimate attached — and the reasoning written down so you can disagree with it.

   Most engagements that go badly went badly before any code was written: the scope was a sentence, the estimate was a guess against that sentence, and the first real week made both obsolete. Discovery is the cheapest way to find that out — deliberately small, deliberately paid, and it produces a document rather than a commitment.

   Discovery ends at the plan. Implementation is a separate decision, made after you have read it — including the decision to make it with somebody else.

2. 02

   Project

   A defined piece of work with a beginning and an end — a feature, an integration, a migration, or a build that has stalled and needs finishing.

   Inside the scope

   • A written scope with explicit boundaries, agreed before the first commit
   • Implementation, tests, and a deployment path that your team can run
   • Code review conversations, not just merged pull requests
   • Documentation aimed at the next maintainer, not at us
   • A handover — a walkthrough, and time for questions after the work ships

   Outside it

   • Open-ended scope. Changes are re-scoped in writing, not absorbed quietly
   • Ongoing maintenance after handover — that is a Retainer
   • Design work beyond implementing an existing direction
   • Staff augmentation. We take responsibility for outcomes, not for filling a seat

   Scope risk sits with us once the boundary is agreed — that is what a fixed scope buys. Which is also why the boundary is written down before the first commit rather than discovered on week ten.

   Scope is written down before work starts, including what is out of it. That document is what makes “this is extra” a conversation on week two rather than an argument on week ten — and when the scope does need to change, and it sometimes does, it changes in writing with a revised estimate attached.

   The end state is a handover, not a dependency. If your team cannot maintain what we built after we leave, the work is not finished, whatever the test suite says.

3. 03

   Retainer

   A recurring block of our time each month, for the work that is continuous rather than shaped — maintenance, upgrades, review, and being reachable when something breaks.

   Software does not stop needing attention when it ships. Dependencies age, platforms deprecate, and the small maintenance tasks each look ignorable right up until several of them combine into an outage. A retainer buys a predictable amount of our attention every month, aimed at whatever you decide is most valuable that month.

   What it is not is an on-call contract. A retainer is booked capacity, not cover: there is no on-call rotation and no guaranteed response time, because a monthly block cannot honestly promise one. We would rather tell you that now than discover it together at two in the morning.

Not sure which one fits? Each kind of work names the one it usually starts in — and if it is still unclear, say so in the form. Working that out is the first thing we would do anyway.