Alpha-Beta-Final Workflow (CQ)¶
Owner: Vi | Updated: 2026-02-05
Purpose¶
This is how we build features at CQ. Every feature goes through three phases: Alpha → Beta → Final. The goal is fast iteration toward solutions, not perfect specs upfront.
The philosophy: - With AI tools (Claude, GPT, Cursor, etc.), developers can be 10x engineers - We don't need full specs to start—we experiment and iterate - The more we iterate, the faster we reach perfection - Don't reinvent the wheel—imitate the best products in market
The Bicycle Analogy¶
The client wants a car. Build a bicycle first.
Wrong approach: Spend weeks building a perfect engine before the client sees anything.
Right approach: Build a bicycle (or even just a seat + wheels + steering). Show the client. Iterate toward the car.
Alpha: 🚲 Bicycle (basic prototype, proves the solution)
Beta: 🛵 Scooter (70%+ there, users can use it)
Final: 🚗 Car v0.1 (complete feature set)
The point: Deliver a working solution fast. Don't get lost in technical perfection early.
The Flow¶
┌─────────────────────────────────────────────────────────────────────┐
│ │
│ ALPHA BETA FINAL │
│ ───── ──── ───── │
│ │
│ Experiment Refine Complete │
│ Find solution Ship to prod Full feature set │
│ (bicycle) (beta flag, 70%+) (v0.1) │
│ │
│ ≤ 3 days 1-2 weeks 2 weeks - 1 month │
│ │
│ ↓ ↓ ↓ │
│ [Feedback] [Feedback] [Erik Approves] │
│ │
└─────────────────────────────────────────────────────────────────────┘
Phase Definitions¶
Alpha: "Experiment and Find the Solution"¶
| Attribute | Description |
|---|---|
| Goal | Prove a solution works—not a feature spec, a SOLUTION |
| Duration | 3 days maximum |
| Who | Dev + Vi (PM) |
| Output | Basic prototype, happy path works |
| Mindset | Build the bicycle, not the engine |
What triggers Alpha: - Rough idea from Erik or Ryan - Examples: "Build a task management system" / "Add AI-powered search" / "Create a way for asset managers to communicate with LPs" - Look at best-in-market products for direction (don't reinvent the wheel)
What Alpha IS: - Basic prototype that achieves the core solution - Happy path working - Enough to show stakeholders "this is the direction" - Experimentation—try things, learn fast
What Alpha is NOT: - Perfect architecture - All edge cases - Polished UI - Production-ready code
The dev's job at Alpha: - Understand the MISSION, not just the feature - Think in solutions, not technical specs - Ask: "What problem are we solving for the user?" - Build the simplest thing that proves the solution works
Alpha Review: Dev + PM review together. Does this direction solve the problem?
Exit Criteria: Stakeholder sees prototype, confirms direction → proceed to Beta with feedback
Beta: "Refine and Ship Under Beta Flag"¶
| Attribute | Description |
|---|---|
| Goal | Incorporate feedback, get to 70%+ complete, ship to production |
| Duration | 1-2 weeks |
| Who | Dev + Vi + QA |
| Output | Working feature in production (beta flag), users can use core functions |
| Quality | 70%+ of final feature, proper UI (not mockup) |
What's different from Alpha: - Alpha = experimentation (find direction) - Beta = refinement (clear direction, now build it properly)
What Beta IS: - Feedback from Alpha incorporated - Clear direction of what to build - Proper UI (not mockup—real interface) - Core functions work end-to-end - Ships to production under beta flag - Users can achieve the main goal
What Beta is NOT: - Just 30% of the feature (must be 70%+) - A mockup - Hidden in staging forever
Example - Cold Email Outreach: - Alpha: Can send an email and see response - Beta: Can send email, receive replies, basic tracking (70%+ there)
Example - AI Natural Language Search: - Alpha: Type query, get some result - Beta: Type query in natural language, get relevant results in user's language (70%+ there)
QA at Beta: - QA performs minimum test set - Dev owns fixing and refining bugs - Dev should deeply understand what they're building
UI/Design at Beta: - UI review happens - Design gives advisement - No major design work yet (things can still change)
Exit Criteria: Feature in production (beta flag), 70%+ complete, core functions work → proceed to Final with feedback
Final: "Complete v0.1 Feature Set"¶
| Attribute | Description |
|---|---|
| Goal | Complete feature set, production-ready v0.1 |
| Duration | 2 weeks typical, up to 1 month max |
| Who | Dev + Vi + Designer + QA |
| Output | Full feature ready for all users |
| Approved by | Erik |
By Final, the dev is the expert: - Can teach the entire team what they're building - Can speak for the client (understands what client actually wants) - Can instruct the designer on requirements - Can delegate or request specifics from other devs confidently
Designer at Final: - Designer was already involved in Beta (shares same view) - Now does full design work - Dev instructs designer on what's needed
What Final IS: - Complete set of features user wants - Everything works end-to-end - Polish and refinement - v0.1 ready for real usage
Example - Cold Email Outreach Final: - Upload contact list - Draft emails - Set sending schedule - Create multi-email sequences - Track engagement - Handle replies - Full workflow complete
Exit Criteria: Erik approves → Deploy to all users (remove beta flag)
Timeline Summary¶
| Phase | Duration | Output |
|---|---|---|
| Alpha | ≤ 3 days | Prototype proving solution |
| Beta | 1-2 weeks | 70%+ feature in production (beta flag) |
| Final | 2 weeks - 1 month | Complete v0.1 |
When to Skip Phases¶
Not everything needs full Alpha-Beta-Final:
| Situation | What to Do |
|---|---|
| Hotfix / bug in production | Go straight to deploy |
| Very small change (text change, minor tweak) | Just ship it |
| No coordination needed | Skip Alpha, maybe skip Beta |
| New complex feature | Full Alpha → Beta → Final |
Use judgment. The process exists to help, not slow you down.
Multiple Features at Once¶
Devs can work on multiple features simultaneously: - Feature A in Beta while Feature B in Alpha - Context switching is OK if reviews are fast
Key: Reviews should be immediate so devs aren't blocked.
The Dev's Journey Through Phases¶
| Phase | Dev's Role | Dev's Understanding |
|---|---|---|
| Alpha | Experimenter | "I'm exploring how to solve this" |
| Beta | Builder | "I know the direction, now I'm building it properly" |
| Final | Expert | "I can teach the team and speak for the client" |
By the end of Final, the dev should know: - What the client actually wants (not just what they said) - Why each decision was made - How to explain the feature to anyone
Common Mistakes¶
| Mistake | Why It's Wrong | Do This Instead |
|---|---|---|
| Building perfect engine at Alpha | Client needs to see solution first | Build the bicycle |
| Focusing on technical details over solution | We solve problems, not build features | Ask "what problem does this solve?" |
| Beta is only 30% complete | Beta must be 70%+ usable | If not 70%, stay in Alpha |
| Beta never ships to production | Users need to use it under beta flag | Ship to prod with beta flag |
| Final adds new features | Final completes existing scope | New features = new Alpha |
| Dev can't explain the feature | Dev doesn't understand deeply enough | Dev should be able to teach others |
Integration with Other SOPs¶
| SOP | When to Use |
|---|---|
| Daily Dev Update | Every day, report phase + progress |
| Stakeholder Feedback | At Alpha and Beta reviews |
| Blocked Protocol | When stuck at any phase |
| Decision Request | When you need a decision to proceed |
FAQ¶
Q: What if Alpha takes more than 3 days? A: You're probably over-building. Alpha should be rough. If genuinely complex, talk to Vi about scope.
Q: Can Beta be less than 70% complete? A: No. If it's less than 70%, you're still in Alpha. Stay there until you have clear direction.
Q: Does Beta really go to production? A: Yes, under a beta flag. Real users use it. That's how we get real feedback.
Q: What if client changes direction at Final? A: Major changes = new Alpha cycle. Final is for completing agreed scope, not pivoting.
Q: How do I know if I truly understand the feature? A: Can you teach it to someone else? Can you explain what the client actually wants (not just what they said)? If yes, you understand it.
Q: What does "speak for the client" mean? A: You understand their needs so well that you can make decisions on their behalf. You know what they'd want even if they haven't said it.
Summary¶
| Phase | Goal | Mindset | Duration |
|---|---|---|---|
| Alpha | Find the solution | Build the bicycle | ≤ 3 days |
| Beta | Refine, ship 70%+ | Ship to production (beta flag) | 1-2 weeks |
| Final | Complete v0.1 | Dev is the expert | 2 weeks - 1 month |
Iterate fast. Solve problems. Don't build perfect engines before the client sees a bicycle.