/KEY TAKEAWAYS
The short version
- 01Thirty days is not a marketing number. It is four scoped phases, four days to decide what you are building, eight to design it, fourteen to build it, four to launch it, and every phase has a hard exit.
- 02Scope drift kills more thirty-day sprints than bad engineering does. The discipline is not writing more code faster. It is refusing to add a feature after day four.
- 03A hardened MVP is not a smaller version of the full product. It is the single feature that proves or disproves the business model, built to a standard that will not need rebuilding when it works.
- 04Weekly releases inside a thirty-day sprint are not optional polish. They are the only mechanism that catches a wrong assumption on day seven instead of day twenty-eight.
- 05Zero drift means the feature shipped on day thirty is the same feature agreed to on day four. Everything discovered in between becomes a note for Version 2, not a change to the current scope.
Founders come to a thirty-day sprint with a product in mind. They rarely come with a feature. Those are different things, and the first four days exist to force the distinction before anyone opens an editor.
How do you scope an MVP down to the single feature that proves the business model?
Ask what would have to be true for someone to pay you, and strip everything that is not directly evidence of that. Not the login screen, not the settings page, not the second user role. One feature, used by one type of person, that either produces the behavior your business model depends on or does not.
Write kill criteria on day four, in the same document as the scope. A specific, numeric threshold that would make you conclude the assumption was wrong. Founders resist this step more than any other, because it means committing in writing to a number that might prove them wrong in three weeks. That resistance is exactly why it has to happen on day four and not day thirty.
What happens during the design phase before any code is written?
Days five through twelve produce two artifacts that matter and a lot of throwaway sketches that do not. The first is a data model, drawn as an actual schema, not a wireframe with boxes labeled data goes here. The second is a wireframe of the single feature's happy path, deliberately excluding every edge case that will not be handled before day thirty.
This phase is where most of the arguing happens, and it is supposed to. Better to argue about a schema on a whiteboard on day eight than discover it is wrong in production on day twenty-five. The exit criterion for this phase is not a beautiful design file. It is a schema and a happy path that both engineers and the founder have actually agreed to, in writing.
FIG/02{
"sprint": "30-day-lab",
"day": 4,
"status": "locked",
"single_feature": "Founders can create a project and invite one collaborator to comment on a shared timeline.",
"explicit_non_goals": [
"Roles and permissions beyond owner and commenter",
"Notification preferences",
"Any billing or plan tier",
"A mobile app"
],
"kill_criteria": "If fewer than 3 of the first 10 pilot users invite a collaborator in week one, the business model assumption is false, not the execution.",
"signed_off_by": ["founder", "lead-engineer"]
}This file gets committed to the repository on day four and referenced, not renegotiated, for the rest of the sprint. The non-goals list is doing as much work as the feature itself.
What does a weekly release cycle look like during a 30-day software sprint?
Days thirteen through twenty-six are the build phase, and it ships weekly, not on day twenty-six. Three releases inside a fourteen-day build window, each one a genuinely deployable slice of the single feature, reviewed by the founder within a day of shipping.
The reason is not ceremony. A wrong assumption caught in a week-one release costs a conversation. The same assumption, undiscovered until day twenty-eight, costs whatever is left of the sprint. Weekly releases are a forcing function that makes the cost of being wrong small and frequent instead of large and terminal.
This is also where the scope lock from day four earns its keep. A founder who sees a working release in week one will want to add to it. The locked document is the answer to that instinct, not a debate reopened every Monday.
FIG/03/TRADE-OFFS
Open-ended MVP build vs the 30-Day Lab Protocol
The open-ended build is not lazy. It simply has no mechanism that forces the hard conversations to happen early, so they happen late instead, when they cost more.
| Criterion | Open-ended build | 30-Day Lab Protocol |
|---|---|---|
| Scope decision point | Ongoing, revisited whenever a new idea feels urgent. | Locked in writing on day four, referenced not renegotiated. |
| Design phase | Happens in parallel with build, discovered as issues arise. | Eight dedicated days producing a schema and a happy path before code starts. |
| Release cadence | One release, at the end, when it feels ready. | Weekly, deployable slices reviewed within a day of each release. |
| Kill criteria | Rarely written down. Failure is felt rather than measured. | A specific numeric threshold, agreed in writing before building starts. |
| Feature creep risk | High. Every good idea has somewhere to go. | Low. Good ideas after day four go into the Version 2 note, not the sprint. |
| Launch readiness | Assessed once, at the end, often optimistically. | A dedicated four-day phase for hardening, load testing, and handover. |
| Cost predictability | Loose. Timeline extends to absorb whatever gets added. | Fixed. The scope moves to fit the calendar, not the other way around. |
| What day thirty produces | Whatever got finished, which may or may not answer the original question. | A clear answer, positive or negative, to the assumption written down on day four. |
What happens in the last four days, and why isn't launch the finish line?
Days twenty-seven through thirty are hardening, not building. Load testing the single feature against a realistic guess at week-one traffic, checking that the authorization and validation discipline held under the deadline pressure of the previous two weeks, and writing the handover document a new engineer could deploy from without a Slack message.
Launch day is day thirty, not day one of the real work, but it is also not the finish line. It is the day the kill criteria written on day four finally start collecting evidence. Everything after that belongs to a different process entirely, the continuous one, running weekly releases against real user data instead of a locked scope document.
Who is the 30-Day Lab Protocol actually for?
Founders who already know roughly what they need to prove and want a process that will not let the calendar slip while they figure out the rest. It is a poor fit for a genuinely open-ended research question, because thirty days is not enough time to explore, only enough time to test one specific, well-formed hypothesis.
/FAQ
Questions founders actually ask about 30-day sprints
- How do you scope an MVP down to the single feature that proves the business model?
Ask what would have to be true for someone to pay you, then strip everything that is not direct evidence of that. Write specific, numeric kill criteria alongside the scope on day one, so success or failure is measured against a threshold agreed before building started, not judged afterward by feel.
- What does a weekly release cycle look like during a 30-day software sprint?
Three deployable releases across the fourteen-day build phase, each reviewed by the founder within a day of shipping. The cadence exists to catch a wrong assumption in week one, when it costs a conversation, instead of week four, when it costs whatever is left of the sprint.
- What are the four phases of a 30-day MVP sprint?
Scope, days one through four. Design, days five through twelve. Build, days thirteen through twenty-six, released weekly. Launch and hardening, days twenty-seven through thirty. Each phase has a hard exit before the next one begins.
- What does zero drift mean in an MVP sprint?
It means the feature shipped on the final day is the same feature locked in writing on day four. Good ideas that surface during the sprint still get captured, but as a note for the next version, not as a change smuggled into the current scope.
- Is a hardened MVP the same as a prototype?
No. A prototype is disposable by design. A hardened MVP is built to a standard where the single feature that works does not need rebuilding once the business model assumption behind it is validated, which is the difference a dedicated hardening phase is meant to guarantee.
- Who is the 30-Day Lab Protocol not a good fit for?
Founders with a genuinely open-ended research question rather than a specific, testable hypothesis. Thirty days is enough time to test one well-formed assumption under a locked scope. It is not enough time to explore several possible directions at once.