Engagements
Three ways to work together.
The organising principle is who carries scope risk. Discovery bounds it for both sides; a fixed-scope project moves it onto me, which is only safe after discovery; a retainer shares it.
How an engagement runs
The shape is the same whichever model fits. Discovery and support are the two ends of it, and they are also two of the three models below — which is the simplest way to say how they connect.
01
Discovery
Two or three weeks mapping the actual problem, ending in a written plan and a fixed-scope quote. The plan is yours either way — you can take it to someone else.
02
Build
Fixed scope, a staging URL from the first week, and something to look at every week after that. No invoice arrives before the thing it is for.
03
Launch
Deploy, monitoring, and the handover written while it is still fresh rather than reconstructed from memory six weeks later.
04
Support
The part most contracts leave out. A retainer keeps someone accountable for the system after the interesting part is over.
Discovery
A short, paid engagement that turns "we think we need X" into a plan you could hand to any competent engineer.
- How it runs
- One to two weeks. Fixed scope, fixed fee, agreed before it starts.
- What you end up with
- A written assessment you own outright — the problem as I actually found it, two or three routes forward with their trade-offs, and a scoped estimate for the one I'd recommend.
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 of work made both obsolete.
Discovery is the cheapest way to find that out. It is deliberately small, it is deliberately paid, and it produces a document rather than a commitment.
You own the output. If you take the assessment and hand it to someone else, or to your own team, that is a legitimate result and I have no claim on it. Being the person who writes the plan does not entitle me to the work — and an engagement that only makes sense if I win the next one is not advice, it is a sales call.
What I will not do is recommend a rewrite by reflex. Rewrites are the most expensive answer available and the least often correct. If the honest finding is that the system is fine and the problem is somewhere else, that is what the document will say.
Includes
- A read through the codebase, the infrastructure, and whatever docs exist
- Conversations with the people who actually use and maintain the thing
- A written assessment — findings, risks, and what I'd do about each
- Two or three routes forward, each with what it costs you and what it costs later
- A scoped estimate for the recommended route
Not included
- Implementation. Discovery ends at the plan
- A commitment from either of us to work together afterwards
- A rewrite recommendation by default — most of the time that is the wrong answer
Usually the right fit when
You have a problem but not yet a specification · An estimate you were given feels wrong and you can't say why · You inherited a codebase and need to know what you're holding · The last attempt stalled and nobody has said out loud why
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.
- How it runs
- Typically four to twelve weeks. Scoped in writing first, invoiced against milestones, with a named point of contact on your side.
- What you end up with
- The thing works, it is deployed, it is documented, and your team can maintain it without me.
This is most of the work. Something needs building, it has a shape, and it needs to be done well enough that nobody has to come back to it.
Scope is written down before work starts, including what is out of it. That document is what protects both of us — it is what makes "this is extra" a conversation on week two rather than an argument on week ten. When the scope does need to change, and it sometimes does, it changes in writing with a revised estimate attached.
I work against milestones you can actually see. Not status updates about progress toward a milestone — the milestone itself, deployed somewhere you can click on.
The end state is a handover, not a dependency. If your team cannot maintain what I built after I leave, the work is not finished, whatever the test suite says.
Includes
- 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 me
- A handover — a walkthrough, and time for questions after the work ships
Not included
- 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. I take responsibility for outcomes, not for filling a seat
Usually the right fit when
A feature your team can't get to, with a date attached · An integration or migration that needs to go right the first time · A build that stalled and needs someone to finish it rather than restart it · Work that needs to survive the person who wrote it leaving
Retainer
A recurring block of my time each month, for the work that is continuous rather than shaped — maintenance, upgrades, review, and being reachable when something breaks.
- How it runs
- A fixed number of days per month, booked in advance, renewed monthly. Either side can end it with a month's notice.
- What you end up with
- Someone who already knows your system is available before you need them urgently, and the small things get done before they become large ones.
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 my attention every month, aimed at whatever you decide is most valuable that month. Some months that is upgrades and unglamorous maintenance. Some months it is reviewing your team's work. Some months it is a small feature that would be awkward to scope on its own.
What it is not is an on-call contract. I am one person. A guaranteed response time from one person is a promise that breaks the first time I am on a plane, and I would rather tell you that now than discover it together at two in the morning. What you get is someone who already knows your system, who has time booked for you, and who will tell you honestly when something needs more than a retainer can give it.
Includes
- An agreed number of days per month, spent on what you decide matters most
- Dependency, runtime and platform upgrades before they become forced
- Code review and technical input for your own engineers
- Small features and fixes without re-scoping each one
- A standing conversation each month about what to spend the next block on
Not included
- A guaranteed response time or on-call rotation. I am one person, and a 24/7 promise from one person is not a real promise
- Unused days rolling over indefinitely — the month is the unit
- Large features. When something needs more than the block, we scope it as a Project
- First-line support for your users
Usually the right fit when
You have software in production and no one whose job it is to tend it · Dependency and platform upgrades keep sliding down the list · You want an experienced reviewer on the team's pull requests · Work arrives steadily but never in project-sized pieces
If what you need is a single-page brochure site, a template will serve you better than I will — and I’ll tell you which one.
If you’re not sure which of the three fits, say so in the form. Working that out is the first thing we’d do anyway.
Start a conversation