Consulting · The Build Sprint

Two weeks.One thing shipped.The method stays.

This is deliberately not a training course. We ship something real on your own codebase, and the training is a side effect of you watching it happen and then doing it yourself in week two.

Book the free 30-min callSee the two weeks, day by day
  • [PLACEHOLDER: Build Sprint price]
  • 2 weeks
  • Remote · your repository, not a sandbox
  • Four weeks of async follow-up after
  • One sprint at a time

Who this is for

The sprint assumes you have already decided what to build.

It compresses execution. It cannot compress a decision, and the fortnight goes badly for anyone hoping it will make one.

  • 01

    The founder who is the queue

    Bootstrapped · pre-seed · seed

    Everything you want built goes through one or two people and they are always full. You can describe the feature precisely in a meeting and still watch it take six weeks, because the description never made it into a form anyone could execute literally.

  • 02

    The product lead who cannot get past the demo

    Heads of product · technical PMs

    You can prototype anything in an afternoon and ship none of it. The gap between something that runs on your laptop and something that runs in production is where every one of these projects has died, and it has died the same way each time.

  • 03

    The operator with a backlog nobody will quote

    Ops · marketing · business owners

    You have five internal tools that would each save a person a day a week, and none of them will ever be worth an engineer's quarter. They are exactly the size of thing this method is good at, and exactly the size of thing that never gets built.

When I say no.

I turn down roughly half of the sprint enquiries I get, and it is nearly always one of these five. Reading them is faster than an email exchange.

  • You have no product and no decision yet. The sprint compresses something you have already committed to; it is a very expensive way to run discovery.
  • You want me to be your engineering team for a fortnight and then leave. The whole point is what is left behind, and an engagement where you never touch it has failed even if the feature ships.
  • Nobody on your side can give me half an hour a day. Two weeks of my time against none of yours produces a working feature your company cannot maintain, which is worse than not shipping it.
  • Your codebase cannot legally be shown to an outside contractor. Sort that out first: the sprint runs on the real repository, and running it on a sandbox removes the part that makes it work.
  • You need a regulated or safety-critical system built by people who carry liability for it. That is not this, and I will tell you so on the free call rather than after an invoice.

The problem

The estimate was two weeks. It is week seven.

The thing that makes this expensive is not that software is hard. It is that the specification was incomplete and nobody found out until something tried to execute it. A human engineer quietly fills the gaps (from context, from experience, from what the last three features looked like) and the bill for those silent assumptions arrives at the demo, when it turns out the thing in your head and the thing in theirs were never the same thing.

So you go round again. The second estimate is more honest and still wrong, because the gaps that remain are the ones nobody knows are there. By the third pass the feature has cost more than it earns and everyone has stopped saying so out loud.

AI tooling does not fix this by being clever. It fixes it by being completely literal: it will not fill a gap from context, it will fill it with something plausible and wrong, immediately and visibly, for the cost of ten seconds instead of three weeks. That is not a downgrade from a human contractor. It is the fastest specification test that has ever existed, and it only works if you treat the output as evidence about your brief rather than evidence about the model.

That is the whole method, and it took me months to see because I spent the first few weeks writing better prompts instead of better briefs. The sprint exists so you skip the months. Two weeks, on your real product, with the loop run enough times in front of you that you can run it without me.

The two weeks

Day by day, so you can see where your time goes.

Roughly half an hour of yours a day, plus two longer working sessions a week. The rest is my time, on your repository, recorded.

  1. 00

    Before day one: access and one decision

    Repository access, a look at how you currently ship, and one thing chosen and cut down until it can genuinely ship in ten working days. The cutting-down is the part clients push back on and it is the single highest-value hour of the sprint. [PLACEHOLDER: current Build Sprint availability, the next start date you can commit to]

  2. 01

    Days 1–2: I write the first specification and you watch

    Screen shared, narrated, no editing. You see the constraints, the edge cases, the target file, the definition of done and the explicit list of what must not be touched, and then you see what comes back and where it is wrong. The wrongness is the teaching material, which is why this part is not a slide deck.

  3. 02

    Days 3–5: the loop, on the real thing

    We run it repeatedly against your actual stack. Claude Code gets configured for your repository as we go (CLAUDE.md, skills, hooks, permissions) because a configuration written against a real codebase is worth more than a template written against nobody's.

  4. 03

    Days 6–8: you write the briefs and I correct them

    The handover starts halfway through, not at the end. You write, I mark up, and by the third one the corrections are stylistic rather than structural. This is the point where most people realise the skill they needed was one they already had from writing briefs for humans.

  5. 04

    Days 9–10: it ships

    To production, on your infrastructure, with whatever review your team normally requires; the sprint does not get an exemption from your own process. If it is not going to make it, you find that out on day six rather than day ten, and we cut scope rather than quietly slipping.

  6. 05

    Weeks 3–6: async follow-up

    Four weeks of questions by email as you do the next one alone. This is where most of the durable learning happens, because the first thing you ship without me is the first honest test of whether the method transferred.

What is in it

Itemised, including the parts that are not.

Everything included

  • Two weeks working directly on your product, not a sandbox
  • One real feature or MVP shipped to production
  • Your specification templates, written against your actual stack
  • Claude Code configured for your repo: CLAUDE.md, skills, hooks, permissions
  • Recorded working sessions you can hand to a new hire
  • Four weeks of async follow-up after we finish

What is not in it: an engineering team, a design system, ongoing maintenance, or any promise that the one thing we ship is the right thing to have built. Choosing that is your job; I will argue with you about it during the scoping hour, which is not the same as deciding it for you.

The price

One number, and what protects you against it.

The refund below is quoted from the same place the landing page quotes it, because a guarantee that is worded differently in two places is not a guarantee, it is a drafting error waiting to be argued about.

Two weeks, one shipped feature

[PLACEHOLDER: Build Sprint price]

2 weeks

Apply for a sprintCompare all three engagements

The risk is mine, not yours

If you finish the first week of a Build Sprint and do not believe it will pay for itself, tell me and I refund it in full. I have never had to, but the offer is real and it is in the contract: I would rather lose a fee than have someone tell five people it was not worth it.

Terms: [PLACEHOLDER: payment terms (deposit, instalment schedule, and invoicing currency)]

The objections

Four fair challenges to this offer.

Ten working days is not enough to ship anything real.
It is not enough to ship anything you have not scoped, which is why the scoping happens before day one and is ruthless. What ships is one feature or one thin MVP, cut down until it genuinely fits, on infrastructure that already exists. If the honest answer during scoping is that your thing cannot be cut to that size, I will tell you before you pay rather than at the end of week two. A sprint that ships eighty per cent of something is worth nothing, and the failure mode is always scope rather than speed.
I will not be able to keep this up once you leave.
This is the reasonable version of the objection and it is why the second week is you writing and me correcting, rather than another week of me demonstrating. By the end you have written several specifications with the corrections visible, you have the templates against your own stack, and you have the recordings of the sessions. The four weeks of async follow-up exist for precisely this moment: the first one you do alone is where it either transfers or does not, and that is the window I want to be reachable in. What I cannot give you is judgement about what to build. That was never mine to hand over.
My engineers will not want an outsider in the repository.
Frequently true, and usually for a good reason: they have watched a manager wave AI output at a deadline that was never realistic. Two things help. The sprint goes through your normal review process with no exemption, so nothing lands that your team did not approve. And the working sessions are open to whoever wants to sit in, because the engineers who resist hardest at the start tend to become the strongest users; the method rewards exactly the thing they have been asking for since they arrived, which is an actual specification instead of a Slack message and a shrug.
Why not just hire a contract developer for the same money?
Sometimes you should, and if what you need is one feature built and never touched again, a contractor is a cleaner answer; say so on the free call and I will point you at that rather than at this. The difference is what remains afterwards. A contractor leaves you a feature and the same bottleneck; the sprint leaves you a feature and the ability to specify the next four yourself. If you are only ever going to build one more thing, that difference is not worth paying for.

Next step

Nobody buys a sprint from a web page. Start with the free call.

Thirty minutes, no pitch. If the sprint is the right answer I will say so and we will scope it there; if it is not, I will tell you what is, which has more often been the free course or a hire than an engagement with me.

Book the free 30-min callSee the team engagement

P.S. The single most common thing that goes wrong in a sprint is scope, and it goes wrong before day one rather than during. If you come to the call with three things you want shipped, expect me to spend most of the thirty minutes arguing you down to one. That argument is the part you are actually paying for.