Section 04
V1 Feature Set Selection
This chapter selects the v1 scope from the broader feature catalogue. It uses the feature records in /prd/02-feature-specification/, the journey evidence in /prd/03-user-journey-flows/, and the binding architecture rules in /architecture/01-architecture-decisions/.
This is a selection document, not a replacement for the feature catalogue. Feature IDs remain canonical in /prd/02-feature-specification/. If this chapter and the architecture decisions conflict, the architecture decisions win until a later ADR supersedes them.
4.1 — Selection inputs and rules
flowchart TD
Features["Feature catalogue<br/>/prd/02-feature-specification/"] --> Selection["V1 feature set selection"]
Journeys["Journey flows<br/>/prd/03-user-journey-flows/"] --> Selection
Architecture["Architecture decisions<br/>/architecture/01-architecture-decisions/"] --> Selection
MVP["MVP definition<br/>/spec/19-mvp/"] --> Selection
Selection --> Freeze["Feature freeze<br/>/prd/05-feature-freeze/"]| Input | How it is used | Scope rule |
|---|---|---|
| Feature catalogue | Supplies candidate features, dependencies, constraints, and high-level acceptance criteria. | A feature is selectable only if it has a traceable FEAT-* ID or is explicitly named as an MVP scope class in /spec/19-mvp/. |
| Journey flows | Shows whether a feature is needed for first value, return use, purchase, content publishing, or failure recovery. | Primary journey blockers are favoured over secondary engagement ideas. |
| Architecture decisions | Provides hard constraints around canvas performance, local-first behaviour, server-side trust, cultural review, accessibility, and monetisation. | Any feature that weakens an accepted ADR is out of v1 unless a new ADR changes the decision. |
| MVP definition | Supplies the minimum launch promise. | The v1 set must include enough app, backend, content, and release work to satisfy the MVP definition. |
| Open decisions | Identifies unresolved forks. | Open decisions can shape implementation defaults, but they do not authorise scope expansion. |
4.2 — In-scope v1 feature set
The selected v1 set contains 53 user-facing MVP feature records plus 14 supporting infrastructure records documented in /prd/02-feature-specification/ under “Supporting infrastructure dependencies” — 67 records in total bind the freeze. The grouping below is the frozen planning view; the underlying acceptance criteria remain in the feature catalogue.
| Area | Selected feature IDs | Rationale | Journey or architecture driver |
|---|---|---|---|
| Onboarding and retention | FEAT-ONB-001 to FEAT-ONB-009, FEAT-RET-001 | The first session must reach a satisfying fill quickly, capture only useful preferences, and avoid sign-up or paywall friction before value. The retention checklist is the only persistent return-path surface. | JRN-P01; ADR-005; /spec/22-principles/ principle 6. |
| Library and artwork decisioning | FEAT-LIB-001 to FEAT-LIB-004, FEAT-ART-001, FEAT-ART-002 | Users need to browse, resume, understand free versus premium state, and see artist and cultural context before opening artwork. | JRN-P02, JRN-P03, JRN-P04; /spec/04-features/ §4.1–§4.2. |
| Download, cache, and offline reliability | FEAT-DL-001, FEAT-DL-002, FEAT-CACHE-001, FEAT-CACHE-002, FEAT-NET-001 | Offline playable downloaded artwork is a core promise. Download verification and cache reconciliation are not optional polish. | JRN-P03, JRN-A06, JRN-F04 to JRN-F08; ADR-001, ADR-007, ADR-011. |
| Canvas, palette, and accessibility | FEAT-CAN-001 to FEAT-CAN-004, FEAT-PAL-001, FEAT-PAL-002, FEAT-ACC-001 to FEAT-ACC-003 | The canvas is the product. Numbers, palette semantics, hit testing, motion restraint, and tap tolerance must be built into the engine from the start. | JRN-P01, JRN-P02; ADR-003, ADR-010, ADR-012. |
| Progress and identity | FEAT-PROG-001 to FEAT-PROG-003, FEAT-ID-001 to FEAT-ID-003 | Anonymous-first identity, local progress, sync, account upgrade, and merge behaviour protect time-to-aha while preserving later continuity. | JRN-P01, JRN-P02, JRN-A08, JRN-F07; ADR-004, ADR-005. |
| Content-pack monetisation | FEAT-IAP-001 to FEAT-IAP-004 | v1 must prove pack conversion without subscriptions or adverts. Purchase, restore, receipt validation, and entitlement reconciliation are required as one system. | JRN-P04, JRN-A05, JRN-F01 to JRN-F03; ADR-007, ADR-008. |
| Settings and notifications | FEAT-SET-001 to FEAT-SET-003, FEAT-NOT-001 | Users need a home for account, accessibility, child mode, restore, notifications, and preferences. Notifications are opt-in and theme-aware. | JRN-A02 to JRN-A04, JRN-F10; /spec/20-open/ OD-07. |
| Content pipeline, cultural review, and admin tooling | FEAT-CONT-001 to FEAT-CONT-003, FEAT-CULT-001, FEAT-ADMIN-001 | The product cannot launch without a repeatable way to produce, validate, review, upload, preview, and publish culturally approved artwork. | JRN-P05, JRN-A07, JRN-F09; ADR-009, ADR-011. |
| Observability and release gates | FEAT-OBS-001 to FEAT-OBS-003, FEAT-REL-001 | Activation, reliability, purchase, crash, performance, child-mode, and release-gate signals are needed to judge launch readiness and avoid blind rollout. | JRN-F03, JRN-F07; ADR-010; /spec/17-phases/. |
| Supporting infrastructure | FEAT-DATA-001 to FEAT-DATA-006, FEAT-API-001 to FEAT-API-005, FEAT-PROG-004, FEAT-OPEN-001, FEAT-OPEN-003 | Implementation primitives the user-facing v1 set depends on: the data model, the catalogue/sync/purchase/admin APIs, the soft account-prompt trigger, and the resolution of OD-10 and OD-12 copy. Acceptance criteria live in /spec/06-data-model/, /spec/07-data-layer/, and /spec/08-api/. | ADR-001, ADR-004, ADR-005, ADR-006, ADR-007, ADR-011; /prd/02-feature-specification/ “Supporting infrastructure dependencies”. |
4.3 — Required v1 gates
Each gate maps to one or more delivery phases in /spec/17-phases/. The “Delivered in phase” column names where the gate is built; gates remain binding in every later phase.
| Gate | Required evidence | Why it gates v1 | Delivered in phase |
|---|---|---|---|
| Phase 0 canvas proof | All eight Phase 0 metrics pass on the same release build and device class. | The canvas engine is the highest technical risk. A failed proof reopens the stack decision before production implementation. | Phase 0 — proof of concept. |
| Local-first play | Downloaded artwork opens and remains playable offline with local progress persisted. | Offline reliability is part of the product promise, not an enhancement. | Phase 1 MVP app shell, hardened in Phase 2 backend integration. |
| Server-side trust | Purchase validation, entitlement checks, signed premium URLs, admin publish, and role-sensitive operations run through backend authority. | The client cannot be the source of truth for premium access or publication state. | Phase 2 backend integration + Phase 4 monetisation. |
| Cultural review | Every launch artwork has recorded approval before publication. | Cultural integrity is a publish gate and trust requirement. | Phase 3 content pipeline. |
| Child-mode policy | Behavioural analytics are suppressed in child mode beyond the allowed minimal signals. | Child safety and platform compliance shape analytics, purchase, and settings behaviour. | Phase 2 backend integration, audited in Phase 5 production hardening. |
| Accessibility baseline | Always-show numbers, screen-reader semantics, contrast, pattern-fill support, reduce-motion handling, and small-region assistance are implemented. | Accessibility belongs inside the colouring engine. Retrofitting it after launch would create avoidable architectural churn. | Phase 1 MVP app shell — accessibility is built into the canvas from the start. |
4.4 — Out-of-scope v1 features
| Feature or area | Related ID | Deferral reasoning | Re-entry condition |
|---|---|---|---|
| Native universal links, app links, and attribution providers | FEAT-DEEP-001 | Not needed to prove first value, offline play, or pack conversion. Notification routing can use minimal internal handling without adding a full deep-linking programme. | Revisit after first release when artwork, pack, and notification entry points need external routing. |
| Ad-supported access | FEAT-ADS-001 | OD-01 recommends omission. Advert SDKs add privacy, child-mode, and product-tone risk before retention data exists. | Revisit after first-cohort retention data and a child-safe advertising policy. |
| Subscription tier | FEAT-SUB-001 | ADR-008 locks v1 to one-off content packs. Subscription lifecycle complexity would distract from pack validation. | Revisit after pack purchase and retention data. Requires a superseding ADR. |
| User-generated content | FEAT-UGC-001 | Moderation, rights, safety, cultural review, storage quotas, and abuse handling exceed MVP complexity. | Revisit only with a full moderation, rights, and cultural-review model. |
| Achievements, badges, and streaks | FEAT-ACH-001 | Deferred and prohibited in v1 — /spec/02-product/ §2.5 explicitly bans streak mechanics, badges, and daily-reward dialogs in the launch product. The first-steps checklist is the only persistent return-path surface in v1. | Revisit only if first-session return behaviour needs more structure and the design can remain calm and non-game-like. Any reintroduction needs both a tone-of-voice exception and a Six-Dimension Change Exception (see /prd/05-feature-freeze/ §5.5). |
| Social sharing and public profiles | FEAT-SOC-001 | Public identity and sharing introduce privacy, artist-rights, and child-mode concerns. | Revisit after legal/privacy review and content-rights policy. |
| Advanced child profiles | FEAT-CHILD-001 | v1 uses an audience choice and child-mode flag. Multi-child profile management would materially expand account, privacy, and settings scope. | Revisit after family usage evidence and legal review. |
| Audio narration | FEAT-AUDIO-001 | Adds media storage, playback, accessibility, and content-production load outside the initial canvas proof. | Revisit after the artwork pipeline is stable. |
| AI artwork generation | FEAT-AI-001 | High cultural authenticity, rights, and review risk. It could also weaken the curated positioning. | Revisit only with a separate AI content policy and cultural-review process. |
| Merchandise | FEAT-MERCH-001 | Commerce and fulfilment do not help validate the core colouring engine or content-pack model. | Revisit after a clear rights and fulfilment plan. |
| Full admin dashboard | MVP scope class | Tooling-only admin is enough for launch. A full dashboard would slow the content pipeline before the process itself is proven. | Revisit once repeated publishing work shows which operator surfaces are truly needed. |
| Multiplayer | MVP scope class | Adds real-time state, safety, moderation, and social graph complexity unrelated to the v1 proof. | Revisit only after single-player retention and safety foundations are strong. |
| Heavy animation | MVP scope class | Competes directly with the canvas performance budget and calm product tone. | Revisit only where measurement proves no impact on Phase 0-style budgets and reduce-motion behaviour is clear. |
4.5 — Trade-off analysis
| Trade-off | Chosen path | Rejected alternatives | Why this is the v1 trade-off |
|---|---|---|---|
| Fast first value vs rich onboarding | Outcome-led welcome, multi-select preference capture, accessibility quick-set, guided first taps, founder note, and soft account prompt. | Feature tours and carousel walkthroughs, mandatory signup before play, paywall surfaces during onboarding, “ask everything at signup” (birthday, gender, marketing consent). | JRN-P01 shows the aha moment depends on reaching canvas interaction quickly. ADR-005 and principle 6 protect that path. |
| Canvas quality vs feature breadth | Single-surface CustomPainter, spatial-index hit testing, palette, accessibility, and performance instrumentation. | One-widget-per-region rendering, multiplayer co-colouring, social and sharing features, achievements/badges/streaks, heavy animation, user-generated content. | ADR-003 and ADR-010 make the rendering proof the main feasibility constraint. |
| Offline reliability vs backend dependency | Downloads + cache + version reconciliation + local progress + sync queue; bitset-union merge on reconnect. | Any play interaction that waits on the network, server-authoritative region-completion during play, last-write-wins progress sync. | JRN-P02, JRN-P03, and JRN-A06 depend on local-first behaviour. ADR-004. |
| Content integrity vs publishing speed | Bundle validation, cultural review as publish gate, admin upload tooling. | A full admin dashboard for v1, bypassable review status, in-app artist self-publishing, AI-generated launch content. | ADR-009 makes review a technical publish gate, while tooling-only admin keeps v1 smaller. |
| Pack conversion vs monetisation optionality | Content packs, paywall, native StoreKit / Billing purchase, restore, server-side receipt validation. | Subscriptions at launch, rewarded ads, behavioural advertising, in-app currency, paid AI artwork generation. | JRN-P04 validates purchase intent without introducing recurring billing or ad privacy risk. ADR-008 locks pack-only. |
| Child safety vs growth tracking | Child-mode analytics restrictions, OS-level parental controls for IAP, suppressed behavioural events when profiles.child_mode = true. | Behavioural advertising in v1, third-party attribution providers, marketing SDKs that load behavioural ads, age-gated growth experiments. | JRN-F10 and ADR-012 show privacy and accessibility are core constraints, not later clean-up. |
| Notification re-engagement vs acquisition tooling | Opt-in new-artwork notifications routed by selected cultural themes; pre-permission value screen before the OS prompt. | Universal links and app links beyond minimal internal handling, attribution providers (Branch, AppsFlyer), marketing deep-link infrastructure, push without pre-permission screen. | OD-07 supports simple re-engagement, while FEAT-DEEP-001 is not needed for first release readiness. |
4.6 — Freeze baseline and post-freeze process
The v1 feature baseline is prepared on 2026-05-20 and is ready to be frozen by /prd/05-feature-freeze/. The baseline is not formally frozen until the approval table in that chapter is completed.
Post-freeze, a feature can move into or out of v1 only through a Six-Dimension Change Exception (sometimes shortened to 6d). The exception captures the impact across six dimensions — user value, scope, schedule, architecture and dependencies, compliance, and release gates — and identifies the approvers accepting the change. The full process, trigger list, and dimension definitions live in /prd/05-feature-freeze/ §5.5. Small wording clarifications, acceptance-criteria tightening, bug fixes, and implementation details that do not change user-visible scope do not require an exception, but they still need normal review.