Trovella Wiki

Phase Approach

How Trovella defines, scopes, and sequences development phases from foundation through scale.

Trovella follows a four-phase roadmap. Each phase has explicit entry criteria, scope boundaries, and a definition of done. The phase model comes from Guide 25.2 (Implementation Phases) in the Week 0 Decision Sprint, adapted for a solo founder building part-time.

Phase Definitions

PhaseNameDurationGoalRevenue Target
0FoundationWeeks 1--3Monorepo, CI/CD, DB, auth, dev environment, agent workspace, observability$0
1MVP BetaWeeks 4--10Core value on web, Stripe, 20--50 beta usersFirst paying users
2GrowthWeeks 11--20Mobile app, feature expansion$1K--3K MRR
3ScaleWeeks 21--36+Performance, multi-tenant hardening, AI features$5K--10K+ MRR

Current phase: Phase 1 -- MVP Beta Launch. Phase 0 is complete.

Phase 0 Sequencing

Phase 0 established a strict build order based on dependency chains discovered during implementation. The retrospective validated this sequence and corrected the original plan's ordering:

  1. Monorepo scaffolding (TRO-6) -- git, pnpm, Turborepo, ESLint, Prettier, Docker Compose, Vitest
  2. CI pipeline + branch protection (TRO-7) -- GitHub Actions, quality gates, no code merges without CI
  3. Cloud infrastructure (TRO-11) -- GCP projects, Terraform, Secret Manager, Cloudflare DNS
  4. Database + RLS (TRO-8) -- Cloud SQL, Drizzle ORM, tenant isolation policies
  5. Authentication (TRO-9) -- Better Auth, Google OAuth, personal org auto-provisioning
  6. API layer + authorization (TRO-10) -- tRPC, CASL, procedure chain
  7. Observability (TRO-12) -- Pino logging, Sentry, health checks

A key lesson from Phase 0: CI must be the second thing set up, immediately after scaffolding. The first CI run caught an ESLint config bug that would have been silently present for weeks otherwise. The principle: "No code should merge to main without CI verification."

Another ordering correction: GCP project creation must precede database and auth work. Cloud SQL runs inside a GCP project, and Google OAuth requires a GCP project for credentials. The original plan had these in the wrong order.

Phase 0 Interleaving Pattern

Phase 0 interleaved technical scaffolding with product and design decisions:

  • Week 1: Foundation scaffolding (agents, low-attention) + app idea discussion (human-driven evenings)
  • Week 2: Core infrastructure (agents) + design system decisions (human-driven) feeding @repo/design-tokens and shadcn/ui theme
  • Week 3: First feature vertical slices (agents) + UI pattern decisions as features are built (human-driven, just-in-time)

The pattern: decide in the evening, agents build overnight or next day. Product decisions happen just-in-time, ahead of the technical work they inform.

Phase Transition Criteria

Phases do not advance on a calendar schedule. Each phase has explicit gate criteria:

Phase 0 to Phase 1: All foundation infrastructure is operational -- CI gates deployment, auth works end-to-end, RLS enforces tenant isolation, database migrations run automatically, observability captures errors. The gate review is documented in docs/phase-0/.

Phase 1 to Phase 2: Core value delivered on web, at least one paying customer via Stripe, 20--50 beta users actively using the product. Feature flags control rollout.

Phase 2 to Phase 3: Mobile app launched, feature set expanded beyond MVP, MRR at $1K--3K indicating product-market fit signal.

Scope Control

The first six weeks of development are calibration, not planning. AI accelerates some tasks 5x and barely helps others. Milestone dates are not committed until 4--6 weeks of throughput data exists.

Scope is controlled through milestones (Linear Projects). Each milestone defines what is in scope. The rule: resist adding more work until the current milestone ships. Infinite backlogs create infinite stress.

Feature issues cover one week's scope only. If work extends beyond a week, new issues are created weekly rather than carrying over a large issue.

Cross-Domain References

On this page