Skip to content

GetCimple Development Workflow Phases

Purpose

This document defines the three phases of GetCimple development, what happens in each phase, and how we transition between them. It serves as the project's "roadmap backbone" and helps the team stay aligned on current focus.


Current Phase: Planning & Documentation

Start Date: 2024-12-01 (estimated) Target Completion: 2025-Q1 Focus: Comprehensive documentation, feature specifications, architectural decisions


The Three Phases

Phase 1: Planning & Documentation (CURRENT)

Objective: Define what we're building, why, and how, before writing code.

Key Activities:

Documentation: - βœ… Internal business process documentation (MkDocs) - βœ… Customer-facing help documentation structure - βœ… Architecture documentation (database, APIs, deployment) - βœ… Technical implementation guides

Specifications: - 🟑 Feature specifications with stakeholder analysis - 🟑 ACSC Essential 8 control mapping - 🟑 Compliance requirements documentation - 🟑 User journey and UX specifications

Architectural Decisions: - βœ… ADR-0001: Supabase for backend - βœ… ADR-0002: Cloudflare for hosting - βœ… ADR-0003: Kinde for authentication - βœ… ADR-0004: MkDocs for documentation - βœ… ADR-0005: React for frontend - βœ… ADR-0006: pnpm package manager - βœ… ADR-0007: No AI in MVP - βœ… ADR-0008: BMAD-Lite + Agent Skills

Process Setup: - βœ… Agent Skills for Claude Code collaboration - βœ… Definition of Ready and spec checklists - βœ… [[NC:]] marker convention - βœ… Risk log framework

Deliverables: - [ ] Complete internal documentation (MkDocs) - [ ] Core feature specs ready for implementation - [ ] All major architectural decisions documented (ADRs) - [ ] Tech stack validated and documented - [ ] MVP scope defined and agreed


Phase 2: MVP Build (NEXT)

Target Start: 2025-Q2 Estimated Duration: 8-12 weeks Focus: Build and launch first version serving real customers

Entry Criteria (Must Complete Phase 1 First): - [ ] All core feature specs pass Definition of Ready - [ ] No unresolved [[NC:]] markers in MVP specs - [ ] Architecture documented and validated - [ ] Tech stack decisions finalized (ADRs complete) - [ ] Risk log reviewed (all HIGH risks have mitigations) - [ ] Team aligned on MVP scope

Key Activities:

Infrastructure Setup: - Set up Supabase project (Sydney region) - Configure Kinde authentication - Set up Cloudflare Pages deployment - Configure CI/CD (GitHub Actions) - Set up development environments

Core Features (Rule-Based, No AI): - Essential 8 assessment questionnaire - Maturity level calculation - Evidence upload and management - Board compliance dashboard - Management task dashboard - Basic reporting (template-based)

Quality Gates: - Unit tests for business logic (60% coverage target) - Integration tests for API endpoints - E2E tests for critical user flows - Performance testing (< 3 second report generation) - Security audit (ACSC Essential 8 self-assessment)

Deliverables: - [ ] Working application deployed to app.getcimple.com - [ ] 5-10 pilot customers onboarded - [ ] Core compliance workflow validated - [ ] Customer feedback collected - [ ] Production monitoring established

Exit Criteria: - [ ] MVP deployed to production - [ ] 5+ customers using platform successfully - [ ] Core workflow validated (Essential 8 assessment) - [ ] Board reporting generates actual value - [ ] No critical bugs preventing use - [ ] Customer satisfaction >70% (qualitative)


Phase 3: Iterate & Scale (FUTURE)

Target Start: 2025-Q3 Focus: Brownfield feature additions, customer feedback incorporation, scale improvements

Entry Criteria: - [ ] MVP successfully launched and stable - [ ] 5+ customers providing feedback - [ ] Core workflow validated - [ ] Revenue or funding secured for continued development

Key Activities:

Brownfield Development: - Add features to existing MVP codebase - Enhance core workflows based on feedback - Optimize performance bottlenecks - Improve UX based on user data

AI Feature Integration (if validated): - AI-assisted policy analysis - Automated risk identification - AI-enhanced report generation - Intelligent question routing

Scale & Optimization: - Support 100+ concurrent users - Multi-region deployment (if needed) - Advanced caching and optimization - Monitoring and observability improvements

Process Evolution: - Re-evaluate planning frameworks (spec-kit, BMAD v6) - Potentially adopt structured implementation tools - Expand team (hire developers) - More formal sprint planning

Deliverables: - [ ] 3-5 major features added post-MVP - [ ] 50+ active customers - [ ] NPS >40 (promoter score) - [ ] Established product-market fit - [ ] Clear differentiation from competitors


Phase Transitions

Planning β†’ MVP Build

Trigger: All Phase 1 exit criteria met

Transition Activities (1 week): 1. Scope freeze: Lock MVP feature set, defer everything else 2. Technical setup: Infrastructure provisioning, environment configs 3. Backlog creation: Convert specs to implementation stories/epics 4. Sprint 0: Team alignment, tooling setup, first story selection 5. Risk review: Final check of HIGH risks before code

What Changes: - Focus: Documentation β†’ Code - Speed: Thoughtful planning β†’ Fast iteration - Decisions: Strategic (monthly) β†’ Tactical (weekly) - Claude's role: Planning partner β†’ Implementation guide - ADRs: Architectural foundations β†’ Implementation choices

MVP Build β†’ Iterate

Trigger: MVP launched, 5+ customers using

Transition Activities (2 weeks): 1. Customer feedback synthesis: Analyze usage data, interviews, support tickets 2. Prioritization: What to build next based on validated learning 3. Brownfield planning: How to add features to existing codebase 4. Process review: Is BMAD-Lite still working? Need more structure? 5. Team retrospective: What went well in MVP? What to improve?

What Changes: - Focus: Greenfield β†’ Brownfield - Context: Clean slate β†’ Existing code and customers - Risk: Market validation β†’ Feature execution - Decisions: Foundation β†’ Enhancement - Claude's role: Full spec review β†’ Targeted feature additions


How Claude Uses This Document

Load This When:

  • User asks "what phase are we in?"
  • User asks "are we ready to start coding?"
  • Reviewing a spec (check if Phase 1 criteria met)
  • Planning work (understand phase-appropriate activities)

Phase-Specific Behavior:

During Planning Phase (Current): - Focus on spec completeness and clarity - Emphasize Definition of Ready - Flag any implementation discussion as premature - Encourage ADRs for architectural decisions - Push for resolving [[NC:]] markers

During MVP Build Phase (Future): - Focus on implementation velocity - Emphasize testing and quality - Reference existing ADRs for consistency - Track technical debt for post-MVP

During Iterate Phase (Future): - Focus on brownfield impact analysis - Consider existing customers and backward compatibility - Evaluate AI feature additions based on customer feedback


Complexity Scaling Across Phases

Phase 1: Planning

  • Simple spec: 1-2 hours to draft, minimal ADRs
  • Moderate spec: 4-8 hours, may need ADR for approach
  • Complex spec: Multiple days, requires ADR, risk analysis, spike plan

Phase 2: MVP Build

  • Simple feature: 1-3 days implementation
  • Moderate feature: 1-2 weeks, integration testing critical
  • Complex feature: 2-4 weeks, architecture review, performance testing

Phase 3: Iterate

  • Simple enhancement: 1-2 days, brownfield impact minimal
  • Moderate enhancement: 1 week, migration or compatibility needed
  • Complex enhancement: 2-3 weeks, significant architectural impact

Tools & Practices by Phase

Tool/Practice Planning MVP Build Iterate
MkDocs Heavy use Light maintenance Documentation updates
Agent Skills Heavy use Moderate use Targeted use
[[NC:]] markers Critical Less common Rare (most answers known)
ADRs Architectural only Implementation decisions Evolution decisions
Risk log HIGH/MEDIUM Expand to LOW Operational risks
DoR checklist Every spec Every story Every enhancement
Git workflow Docs branches Feature branches Hotfix + feature branches
Planning frameworks BMAD-Lite Re-evaluate Likely adopt if scaled

Success Indicators by Phase

Planning Phase Success

  • βœ… No specs with unresolved [[NC:]] markers
  • βœ… 3-8 ADRs documenting foundations
  • βœ… Risk log <10 active items
  • βœ… All specs pass Definition of Ready
  • βœ… Team aligned on MVP scope

MVP Build Phase Success

  • βœ… Deployed to production
  • βœ… 5+ pilot customers using successfully
  • βœ… Core workflow validated
  • βœ… No critical bugs
  • βœ… Performance targets met

Iterate Phase Success

  • βœ… Features added without breaking existing
  • βœ… Customer satisfaction maintained or improved
  • βœ… Technical debt managed
  • βœ… Established product-market fit

Common Questions

"Are we ready to start coding?"

Check Phase 1 Exit Criteria: - Are all MVP specs complete and passing DoR? - Are all HIGH risks mitigated? - Are architectural decisions documented?

If YES to all β†’ Ready for Phase 2 If NO β†’ Continue Planning

"Should we add this feature?"

Phase 1: Add to spec if strategic, defer if nice-to-have Phase 2: Only if critical for MVP validation, otherwise defer to Phase 3 Phase 3: Prioritize based on customer feedback and data

"Do we need an ADR for this?"

Phase 1: Yes, if architectural and irreversible (database, hosting, auth framework) Phase 2: Yes, if sets implementation precedent (state management pattern, API design) Phase 3: Yes, if affects existing architecture (migration strategy, breaking changes)



Version: 1.0 Created: 2025-10-20 Last Updated: 2025-10-20 Next Review: 2025-11-20 (monthly retro)