What an AI build sprint looks like

Most owners have heard a version of the same software story. The quote was a range. The timeline slipped. The finished thing did most of what was asked, and nobody could agree on whether that counted as done.

A Build Sprint is set up to avoid that story. It is short, it has one job, and the price and the finish line are written down before anyone writes a line of code. This post walks through how one runs, from the signed scope to the weeks after launch.

It starts from the audit, not from a blank page

A Build Sprint builds one thing: the top fix from your audit. By the time a sprint starts, that fix has already been measured. You know roughly how many hours it should give back, what that is worth in a year, and what it costs to build.

That is what makes a short sprint possible. The hard questions, which task, is it worth it, will it work on our information, were answered in the audit. The sprint is for building the answer, not for discovering the question.

Before any work: the scope

Every sprint begins with a signed scope. It is a short document, and it does three things.

It fixes the price. Build Sprints start at $5,000, and the number is fixed and agreed before work starts. There is no hourly meter running in the background. If the work turns out to be bigger than one sprint, that larger work is quoted separately after the sprint, not folded quietly into this one.

It sets the finish line. The scope lists the checks the build has to pass. These are plain statements you can test yourself, the kind of thing you would check on the first morning it is live. "Done" means the build passes those checks. It does not mean "the developer says it is finished."

It names what we need from you. A build connects to the systems you already run, so the sprint needs access to them. The scope says which ones.

When the clock starts

A sprint is live in one to two weeks. That clock is counted from a signed scope and access to your systems.

Both halves of that matter. A signed scope means everyone has agreed on what is being built. Access means we can actually build it. If access to a system takes a week to arrange on your side, that week comes before the clock, not inside it. Knowing this up front lets you plan. The fastest sprints are the ones where the logins and permissions are ready on day one.

How you pay

Payment follows a simple pattern: half to start, half at launch. You are never paying for weeks of work you have not seen.

If you came from an audit, the audit fee comes off the price. Sign a build of $5,000 or more within 14 days of your report and the full $2,500 is credited. On a build at the starting price, that means an audit client pays $2,500 more for the first build.

Launch is part of the sprint

A build that works on a developer's machine is not finished. Putting it live inside your business is part of the job, and it is included in the sprint price.

Launch means the fix is running on your real systems, with your real data, used by the people who do the work. It is checked against the list in the scope. If it passes, it is done. If it does not, it is not done yet.

Handoff: you own it

The sprint also includes a handoff. Your team should know how the new process works, what it does on its own, and where a person still needs to look. A fix only saves hours if the people it was built for actually use it, and they will only use it if they understand it.

The code and the documentation are yours. If you later hire someone else to extend it, they start from what was built, not from nothing.

The first 30 days

Every build is covered for 30 days after launch. The coverage is tied to the same checks in the scope. If, during those 30 days, the build stops passing one of them, we fix it at no charge.

It is worth being clear about what that coverage is not. It does not include changes made by outside vendors, changes made on your side, new requests outside the scope, or fees charged by outside providers. Those are real things that happen to software, which is why there is something after the coverage period too.

After the sprint

When the 30 days are up, you have three sensible paths.

• Run it yourself. The build is yours, along with its documentation.
• Add a Care Plan. Ongoing support is available after a build, so the fix keeps working as your tools and the AI models behind it change.
• Build the next fix. Your audit ranked several. Larger work, or the next fix on the list, is quoted separately.

None of these is required. The sprint is complete on its own.

Why one fix at a time

It can be tempting to bundle everything into one big project. The trouble is that big projects carry big guesses, and every guess comes with padding.

One fix, a fixed price, a short clock and a written list of checks keeps the guesswork small. You see something real working inside your business within weeks. You learn how your team takes to it. Then you decide, with actual results in hand, whether the next fix on the list is worth building.

A good first step

A Build Sprint starts from an audit, so the place to begin is there. If you want to see how ready your business is first, the free AI readiness quiz takes under five minutes. Or book thirty minutes and we will talk through what a sprint could look like for you.