The governance sprint model explained: what happens in 2 weeks and what you own at the end

If you are considering a governance sprint, here is exactly what happens, in what order, and what you walk away with. No ambiguity.

Discovery (Days 1-2)

We ask questions. Where does your data live? What systems does your team use today? What is the manual process that consumes the most time? What compliance requirements apply? What has been tried before and why did it fail?

We are not selling during discovery. We are scoping. If the sprint is not the right fit for your situation, we say so here. A sprint works when there is a clear problem, accessible data, and an internal champion willing to drive the engagement. If those three things are not present, a sprint will produce tools that nobody maintains.

Design (Days 3-4)

We map out exactly what gets built. Not a proposal document. A wireframe of the actual tool, the database schema it will use, and the workflow it will replace.

You see the design before any code is written. You approve it. If the design misses something, we change it now, not during the build phase.

The design phase also produces the CLAUDE.md for your project. This is the governance document that will govern how AI tools interact with your codebase going forward. It defines data handling rules, coding standards, and compliance requirements specific to your organization.

Build (Days 5-8)

We build in front of you. Screen-shared sessions. You watch the Claude Code workflow in real-time. You see how the tool talks to the database, how the interface gets constructed, how decisions get made.

This is intentional. We are not building behind a curtain and delivering a finished product. You are watching the method so you can understand it. You can ask questions. You can redirect. You can say "that is not how we handle that data" and we change course immediately.

By the end of day 8, the tool is functional. Not polished. Functional. It connects to your data, performs the workflow, and produces the output your team needs.

Train (Days 9-10)

You drive. We watch.

Your team uses the tool. They modify a field. They change a filter. They add a new feature. They break something and fix it.

This is the phase that separates a governance sprint from a consulting engagement. In a consulting engagement, the consultant builds and leaves. In a sprint, the team learns to build during the engagement. When we leave, the capability stays.

Handoff (Day 10)

You receive the complete code repository. You receive the CLAUDE.md. You receive a written maintenance guide that covers: how to make common changes, how to add new features, how to troubleshoot common issues, and how to update the tool when requirements change.

We are not the phone number you call when the tool breaks. Your team is. That is the point. You own the tool, the code, the documentation, and the capability to extend it.

What you own at the end

The code. No licensing fees. No per-seat pricing. No subscription. The code is yours.

The workflow documentation. How the tool works, what it does, why specific decisions were made.

The CLAUDE.md. Your governance document for future AI development in this project.

The capability. Your team watched the build, participated in the build, and drove the build in the training phase. They can make changes.

What you do not own

A dependency on us. That is intentional. We built a sprint model specifically so that the engagement ends cleanly. You do not need us to maintain the tool. You do not need us to make changes. You are equipped to do it yourself.

Book a sprint inquiry call — sprint inquiry calls are 30 minutes. No slide deck, no pitch.