You should know what the weeks look like before you buy them.

Nothing gets built from a conversation

Every piece of work is defined before anyone starts it, and the bar is specific: could someone pick this up cold and execute it without needing to ask a question? Most missed estimates are a definition failure wearing an engineering costume.

The research that gets a task to that bar is the expensive part, and it's the part I've automated hardest. Reading the relevant code, checking what the logs actually say, finding the three prior attempts at the same thing. That work happens before an estimate exists, not after it's already wrong.

Reality gets checked against the plan

Time passes between defining a task and doing it. Code moves underneath. So the first step of execution is validating the ticket against the current state of the codebase: do the files still exist, have the dependencies actually landed, has anything changed the scope.

It's a five-minute step that routinely saves a day, and it's the difference between "we hit a surprise" and "we hit a surprise in week nine."

You see working software, not status reports

A deployed environment you can click by the end of week two, and everything after that lands in it continuously rather than arriving at the end. A weekly written note covers what shipped, what's next, and anything that changed, but the note is a summary of something you can already see rather than a substitute for seeing it.

Done means validated, in four tiers

• Static. Lint, types, unit tests, build. Blocking on every change. Nothing merges red.
• Integration, post-merge. Real services, real database, contract tests between the pieces.
• Acceptance, before each release. Your criteria, executed as user scenarios against a real browser, with screenshots. Written in plain language, which means you can write them, and so can the person who reported the bug.
• Production, after each deploy. On systems I build, every feature ships with a signal, and error rates and latency get compared before and after. Confidence comes from data rather than from someone saying it looked fine.

What I need from you

Less than you'd expect, but it isn't zero, and the engagements that go badly are usually the ones where these were missing.

• › One person who can make a decision without convening a committee.
• › Access to whoever actually does the work today. Close to the problem is the whole method, and a spec written by someone who has never done the job is a spec about an imaginary job.
• › A response inside about two business days when something is blocked. I'll do the same.

When something goes wrong

Something will. A third-party API turns out to be undocumented fiction, a migration is worse than it looked, a requirement was understood differently by two people in the same meeting.

It goes in that week's note, with the options and what each one costs, rather than surfacing at the end. The line I hold is simple: harder than I thought is mine to absorb, different from what we agreed is a priced change. I'll tell you which one I think it is and why, and if you disagree we settle it before anything gets built. What it never means is quietly absorbing it by cutting the tests.

If I'm hit by a bus

Worth asking, and most studios make you ask it. The answer is structural: nothing about your project lives only in my head or on hardware I control, and the engagement is shaped so that continuity never depends on one calendar.

• › Everything lives in your accounts from day one. Your repositories, your cloud, your vendor accounts. Nothing of yours runs anywhere I control, so there is nothing to hand back.
• › Builds are billed by milestone rather than up front, so your exposure at any moment is one milestone, not the contract.
• › Work lands continuously, so what you have paid for is already deployed and usable rather than sitting half-finished somewhere you can't reach.
• › The operating manual in the repository is written for exactly this case: enough for a new engineer to be useful on day one without me explaining anything.
• › If I'm unavailable for more than two weeks, the engagement pauses and unearned fees come back. That goes in the contract, not just on this page.

What you're left holding

Code you own from the first commit, in your repositories, under your accounts. Documentation written for whoever inherits it rather than for me. The tests and the pipelines that keep it honest. And an operating manual for the codebase specific enough that a new engineer, or their AI tooling, can be useful in it on day one.

The measure of a good handover is that you don't need me afterwards. If you keep me on it should be because the next thing is worth building, not because nobody else can touch it.