Build phase

The build phase is where we ship the thing. By this point the scope is signed, the architecture is sketched, and the team knows what to do — the work is execution, not invention.

How sprints run

We work in two-week sprints. Two weeks is short enough that we can correct course quickly when something is wrong, and long enough to actually finish meaningful chunks of work without breaking everything into pieces too small to evaluate.

Each sprint follows the same rhythm:

Day 1 — Sprint planning

We pick the work for the sprint from the backlog (which came out of discovery and grows as the build progresses). The sprint goal is one or two sentences anyone on the team can recite from memory.

You don't attend planning unless you want to. The output is a list of tickets and a deadline; you'll see both in the project tracker.

Days 2–14 — Building

We build, you don't have to do much. We'll ping you for decisions when we hit a fork. We'll usually have one mid-sprint async update with a Loom or a written status note — no live meeting unless something needs one.

End of sprint — Demo

A 30–45 minute video call where we show working software. Not a slide deck pretending to be progress. The deliverable for the sprint is either there and working, or it isn't.

If something didn't make it, we say so directly and put it at the top of the next sprint. We don't fudge progress to make a checkpoint look better than it is.

What "done" means

A feature is done when:

1. It works end-to-end in the staging environment.
2. It's covered by automated tests where the failure mode would be silent.
3. It's documented in either the codebase, a runbook, or both — depending on whether ops will need it.
4. It's reviewed and merged.

"Done" doesn't mean "the dev pushed code." If a feature can't survive a real-world demo at the end of the sprint, it isn't done.

Reviews and your involvement

We expect roughly 2 hours per week of your time during the build phase: one demo at end-of-sprint, plus async decisions and reviews scattered through the week. Heavier weeks happen — content reviews, integration testing, decisions on ambiguous user flows — but the baseline is light.

If your team needs to be more hands-on (because you have an internal product person, or the system is replacing something they use today), we plan that into the cadence at the start.

When things go sideways

Software builds are uncertain. Halfway through, you'll usually find one of:

• A piece of scope is harder than expected
• A piece of scope turns out unnecessary
• Some new context emerges that changes the priority order

When that happens we surface it the day we see it, not at the next checkpoint. We'll give you the options, the trade-offs, and a recommendation. You decide. The scope doc gets updated and the build schedule, if affected, is rewritten.

See scope changes for how that affects pricing.

Sprint demos as your control plane

Every two weeks, you have a real chance to:

• Confirm we're building the right thing
• Cut scope that no longer makes sense
• Add scope that turned out to matter more than we thought
• Pull the plug, if it's going badly

You don't have to wait until launch to know how the work is going. You'll know on day 14, day 28, day 42 — every two weeks, with working software in front of you.

Where to go next

Launch & handoff → Communication cadence in detail →