POC v1 Playbook
Purpose: Build the first functional version. Prove the core mechanics work.
Duration: 3 days
When to use: After demo review meeting confirms go-ahead.
Inputs Required
- Validated demo
- Requirements from demo review (customer feedback)
- Clear understanding of what "working" means
Principles
Focus: Does it work?
Use synthetic/anonymized data. Don't wait for real data access. Generate test data that looks realistic enough to validate the mechanics.
Prioritize: Core functionality. Does the main thing work?
Use fast defaults:
- Auth & security via our quick-start kit (your production stack comes in v3)
- Any infrastructure—local, cloud, whatever's fastest
- Synthetic data (don't wait for real data access)
Defer to v3:
- Production infrastructure approval
- Client auth stack integration
- Real data sources
- Scale & polish
Ask yourself: "If this works, what would the next version need?" That's your output.
Process
Day 1: Core Loop
Build the main thing. The one workflow that proves the concept. Get it working end-to-end, even if ugly.
Day 2: Supporting Features
Add what's needed to actually use the core loop. Data input, basic output, minimal UI to navigate.
Day 3: Demo-Ready
Clean up enough to show someone. Document the obvious limitations. Prepare the "here's what v2 would fix" list.
Outputs
- Working POC v1
- List of architectural limitations (what won't scale)
- List of functionality gaps (what users will ask for)
- Input for v2 requirements
Tips
- v1 architecture serves v1. Make decisions appropriate to a 3-day build—don't over-engineer for requirements you don't have yet.
- If you're stuck on infrastructure decisions, you're overthinking. Pick one and move.
- The demo was the hypothesis test. v1 is the mechanics test. Different questions.
- "Previous version = requirements for next version." v1's limitations define v2's scope.
Next: Version Transition → POC v2 Playbook