Don't build past v1 of any feature/phase without one real user
Context
Aspire's portfolio of in-house products grew faster than user adoption. Multiple projects (notably the wifi-portal predecessor of Alby Studio) shipped Phases 1-4 with zero real users on the system. By the time a real user showed up, the v4 surface required rework because v1/v2/v3 assumptions were wrong.
Pattern observed: AI-assisted dev accelerates iteration → easy to ship more features than the actual user base demands. Result: dead code, deferred deletion, and accumulated rework debt.
Detail
Decision
One real user must be using v1 of a feature/phase before v2 of THAT feature/phase begins.
Rationale
- v1 → v2 should be informed by real user friction, not speculation about what users might want.
- AI agents are excellent at building speculative v2 features. They have no way to know if v1 is actually used.
- The cost of NOT shipping v2 is small (it just doesn't exist yet). The cost of shipping a wrong v2 is large (rework, refactor, sunk-cost-on-deletion).
Practical heuristics
| Scenario | Apply rule? |
|---|---|
| First customer in beta, asking for a specific v2 feature | YES — they're a real user. Build it. |
| Internal Aspire usage (Kom + 1 team member) | YES — count as 1 real user (low bar) |
| Hypothetical "users will want X" | NO — don't build it |
| Engineering polish that doesn't add user-facing capability (refactor, perf, security hardening) | NOT BLOCKED — these are infra hygiene, not features |
| Existing v1 has obvious bug | NOT BLOCKED — fixing bugs is not v2 |
Generalizes to "don't deploy infra until client #1 signs"
The same principle applies one level up: don't stand up customer-facing infrastructure (e.g., a multi-tenant deploy) for products that don't have a first client lined up. This is already in MEMORY.md as a separate cross-cutting rule (e.g., the Aspire Social Media Service won't have infra until client #1 signs).
Anti-patterns this prevents
- The "complete platform" trap — building all 10 promised features before any 1 is used in production
- Speculative refactoring — restructuring code to support a v2 that may never ship
- Premature abstraction — generalizing patterns based on hypothetical multiple instances
Constraints we accepted
- Some features that "obviously will be needed" will be delayed until they're proven needed.
- Engineering pride may push back ("but this is clearly the right architecture for v2!") — the rule wins.
Revisit trigger
- A product has so many users that v1 → v2 friction is observable per-week and the bottleneck is dev velocity, not user feedback.
Actions
- [x] Wifi-portal lesson logged (4 phases shipped with zero users — won't repeat)
- [x] Alby Studio: friendly-beta (3-5 real vendors) gates real launch per project
_STATUS.md - [x] Knowledge OS Stage 1: production deploy is the v1 gate; Stage 2 won't start until 1k+ queries/day OR FTS demonstrably insufficient (per knowledge-os-stage-1)
- [ ] Future projects: add "v1 user count" check before any v2 task in
/plan
Related
- knowledge-os-stage-1 — Stage 2 (LightRAG) gated by Stage 1 production usage
- aios-workflow — the
/spec→/plan→/buildlifecycle has a natural gate here