Why 14 Days?
Two weeks is long enough to build something real but short enough that you can't hide behind process. You can't spend three days in a design phase. You can't defer hard problems to "next sprint." Every decision happens under pressure, and that pressure reveals what actually matters.
The 14-day constraint isn't arbitrary. It comes from a simple observation: if you can't validate the core hypothesis in two weeks, you probably don't understand the hypothesis well enough.
The Five Steps
1. Write the Hypothesis
Not "let's build a party game." A real, falsifiable hypothesis:
"AI-generated content solves the replayability problem in party games, measured by voluntary replay rate above 50%."
If you can't state the hypothesis in one sentence, you're not ready to build. If it's not falsifiable, it's not an experiment — it's a wish.
2. Write the Brief
One page. Not a PRD, not a spec, not a 40-slide deck. One page that includes:
- The hypothesis (from step 1)
- What you're building (the minimum thing that tests the hypothesis)
- Kill conditions — specific, measurable thresholds that mean "stop"
- Success criteria — what "keep going" looks like
- Timeline — 14 days, broken into rough milestones
The kill conditions are the most important part. They're a contract with yourself. When results come in, you don't get to move the goalposts.
3. Build the Minimum Version
Not an MVP in the startup sense — not a landing page with a waitlist. A real, working product that a real user can actually use. But the minimum version of that.
For localhost-party, this meant: one game mode, four players max, AI narration, phone controllers. No accounts, no persistence, no game library. Just the core loop.
The temptation is always to add "one more feature" to make the test more valid. Resist it. You're testing the hypothesis, not building a product.
4. Measure Real Behavior
Not surveys. Not "would you use this?" questions. Actual behavior data:
- Did they come back without being asked?
- How long did they actually use it?
- Where did they drop off?
- Did they share it?
For localhost-party, the key metric was voluntary replay rate. We didn't ask "would you play again?" — we watched whether they did play again, unprompted.
5. Ship or Kill
This is where most people fail. The results come in, they're mixed, and the temptation is to "iterate" — which usually means "avoid making a decision."
The kill conditions exist for this moment. If the results meet the kill conditions, you kill it. Done. Move on. The time and energy you free up is worth more than another iteration on a mediocre idea.
If the results clear the kill conditions, you ship it — meaning you commit to the next phase of investment (more features, more users, more polish).
What This Looks Like in Practice
localhost-party cleared every kill condition:
- Replay rate: 100% (target: >50%)
- Session length: 34 min (target: >15 min)
- NPS: 72 (target: >40)
Decision: Ship. Move to v2 with multiple game modes and persistent narrator memory.
playoff-best-ball validated the core loop at $0 cost but was seasonal:
Decision: Defer. Revisit for 2026-2027 season with validated assumptions.
taco had architecture complete but core integrations unimplemented when priorities shifted:
Decision: Pause. Not killed (hypothesis still valid), but not worth active investment right now.
Why Kill Conditions Matter
Without kill conditions, you'll always find a reason to keep going. "The metrics weren't great, but the qualitative feedback was positive." "We didn't hit the target, but we learned a lot." "Let's give it one more sprint."
Kill conditions strip away the rationalizations. They're a bright line that you set before you're emotionally invested in the outcome. They're the single most important part of this framework.
Try It
If you're sitting on an idea, write the hypothesis. Set the kill conditions. Give yourself 14 days. The worst case is you learn something. The best case is you build something that works.
Either way, you'll know in two weeks instead of six months.