Home / Build Sprint

Working software in two weeks

Most AI ideas stall somewhere between the slide and the shipped thing. The Build Sprint closes that gap, so the call on a full build gets made against something real instead of an estimate. Two weeks in, not two quarters.

The entry point

The AI Build Sprint

Two weeks. One problem worth solving. A working prototype your team can click, break, and judge. Fixed scope, fixed price, agreed before I start.

Week 1

Frame the problem, map your data, ship the first working slice.

Week 2

Harden it, wire it to your stack, demo it with your team.

You keep

The prototype, the code, and an honest read on what a full build takes.

Why two weeks is enough

The sprint is not open-ended discovery. I turn the problem into a written contract, slice it into buildable stories, and check every slice before it reaches you.

Written contract

I write the problem, the scope, the non-goals, and the acceptance criteria before the build starts. Nothing important lives only in a call or a chat thread.

Clickable before coded

You see the workflow as a clickable screen before code decisions harden. Changes are cheap at that point and expensive once implementation starts.

One slice at a time

The build is split into thin vertical slices. User path, logic, data, and tests move together, so there is no backend-only progress to report.

Checked before you see it

Every slice is checked against the acceptance criteria, the tests, the UI behaviour, and the risk. Anything unclear stops with a written reason rather than a guess.

Who it is for

One idea, ready to test

The sprint works when there is a single opportunity worth proving. If you are still choosing between five of them, say so on the call and I will help you pick one.

Founders with an idea

You have one AI product idea worth testing and you need a working first slice before you raise, hire, or commit a year to it.

Product teams with a workflow

Something in the business is worth automating, but nobody agrees on what to build first or whether AI is the right tool for it.

Operators inside the tools

You want AI working inside the systems your team already uses every day, not sitting beside them in a separate app.

The usual ways AI stalls

Most AI work dies in one of four places. The sprint is shaped to walk past all of them.

No six month discovery

You get working software in two weeks. Anything that cannot be decided in that window was not the real question.

No demo that stalls

The prototype is built the way production is built, so the path from here to live is a shorter version of the same road.

No handoff you cannot run

You keep the code and the reasoning behind it. Your team can pick it up without me in the room.

No tooling picked first

I choose models, frameworks, and vendors after the business problem is clear, never before.

What you keep

Three things, whatever you decide

Nothing here is held back to sell you the next phase. You leave with all of it.

PROTOTYPE

Something to click

A working slice your team can use, break, and argue about. Not a slide about what it would do.

CODE

The repository

Yours from day one. Readable, documented, and built to be extended rather than thrown away.

DECISION

An honest read

What a full build takes, what it costs, and whether the problem deserves one. Including when the answer is no.

The two weeks, step by step

Six steps, each with something you can see at the end of it. Nothing is held back for a reveal at the finish.

Step 01

Scope

Pick one business problem, name the non-goals, and agree what the prototype has to prove.

Step 02

Prototype

Turn the workflow into clickable screens so your team can react before code hardens.

Step 03

Plan

Break the prototype into buildable stories, each with acceptance criteria and a test path.

Step 04

Build

Implement the smallest working slice, wired to realistic data and systems where we can.

Step 05

Gate

Checks, QA, and review. Anything risky or unclear is written down, never quietly dropped.

Step 06

Decide

Demo the prototype, hand over the code, and give the honest recommendation. Build, revise, or stop.

Before you book

What founders and product teams ask before a sprint.

One business problem, the workflow around it, and access to the people who understand it. I help shape the exact scope before the sprint starts, so week one begins with building rather than negotiating.
No. The sprint is built for teams that need senior AI product judgment before they hire or commit to a full build. If you do have engineers, they work alongside me and keep the context.
A working prototype, the code, and an honest read on whether the problem deserves a full production build. All three are yours whatever you decide next.
That is a useful outcome and I will say so plainly. You avoid a much larger bet, you keep what the two weeks taught you, and you leave with clearer next steps.

Have one idea worth proving?

Tell me the problem and who it affects. Thirty minutes, and you leave with a scope and an honest read.