Dogfood Before Selling
We use SmartBoxes ourselves for real work before selling it to customers.
Context
We could start selling SmartBoxes immediately after MVP, or use it internally first to validate and refine. This decision affects product quality, time-to-revenue, and our ability to speak authentically about the product.
Alternatives Considered
| Option | Why Not Chosen |
|---|---|
| Immediate beta release | Faster revenue but risk of poor first impressions, bugs in production, support burden |
| Paid alpha with early adopters | Revenue earlier but requires support capacity we don’t have, could damage reputation |
| Skip internal use entirely | Fastest to market but we’d be selling something we don’t believe in |
The Decision
Use SmartBoxes ourselves for real work for at least 4 weeks before inviting external users.
What “real work” means:
- Using SmartBoxes to develop Murphy and other products
- Running AI agents for actual tasks (code generation, data processing)
- Treating it as our primary development environment, not a demo
- Documenting what works, what breaks, what’s confusing
Why dogfooding:
- Validates the product — if we won’t use it, why would anyone else?
- Finds bugs before customers — we’re the first angry users
- Generates authentic content — real stories, not manufactured examples
- Builds conviction — we know the product intimately when selling
- Creates case study — “we built X with SmartBoxes” is credible proof
Tradeoffs Accepted
What we’re giving up:
- Delays time to first external user by 4+ weeks
- May over-optimise for our own use case (developer, solo, specific workflows)
- Risk of building in a bubble (no external feedback)
- Revenue starts later
What we’re accepting:
- Need to balance dogfooding time with shipping pressure
- Our use case may not represent typical customer
- May discover product doesn’t work for our needs (good to know early)
Reversal Triggers
Revisit this decision if:
- 4 weeks pass without meaningful internal use (we’re not actually dogfooding)
- External demand too strong to delay (waitlist overflowing, press interest)
- Internal use case too different from target market (we’re not learning relevant lessons)
- Runway constraints require faster revenue (burn rate higher than expected)
Early warning signs:
- Finding excuses not to use SmartBoxes ourselves
- Preferring other tools for “real work”
- Internal bugs not being fixed (low priority)
- No content/stories emerging from internal use
Review Schedule
Next review: 2025-03-15 (or at 4-week mark)
Review questions:
- Have we logged 10+ hours/week of SmartBoxes usage?
- What have we learned about the product?
- What bugs/issues have we found and fixed?
- Are we ready for external users?
Related
Depends on assumption:
- Can Ship Fast Enough — can only dogfood if we ship
Supports guiding policy:
Affects product:
Affects milestone:
Tracked by:
Context
We could start selling SmartBoxes immediately or use it ourselves first. Need to decide how to validate the product.
Decision
Use SmartBoxes ourselves for real work for at least 4 weeks before inviting external users.
Rationale
Dogfooding (1) validates the product with a real use case, (2) generates authentic content and case studies, (3) finds bugs before customers do, (4) builds conviction in the product. We can’t sell what we don’t use.
Alternatives Considered
| Option | Why Rejected |
|---|---|
| Immediate beta release | Faster revenue but risk of poor first impressions |
| Paid alpha with early adopters | Revenue earlier but requires support capacity |
Tradeoffs
- Delays time to first external user
- May over-optimise for our own use case
- Risk of building in bubble
- Revenue starts later
Reversal Triggers
Revisit this decision if:
- 4 weeks passes without meaningful internal use
- External demand too strong to delay
- Internal use case too different from target market
- Runway constraints require faster revenue
Depends On Assumptions
- Can Ship Fast Enough — 🔄 60%