# Phone app first — design and implementation kickoff

11 September 2026 · Supersedes the earlier web-first delivery assumption.

**NAAST is a phone app.** Web is a companion for occasional access and a convenient review/testing surface. B3 remains the identity; M3 is Dani’s leading memory layout, with the cofounder’s choice pending. Small clips remain in the launch plan with provisional limits. Dani agrees with the remaining feature scope.

The working release sequence is iPhone first, with Android supported by the architecture. Whether both platforms enter the first pilot is still open. This assumption allows design/foundation work to proceed; it is not a recorded platform preference from Dani.

## 1. What changed in the visuals

The [phone review](../figmaish_pages/phone.html?screen=today) is now the main interactive route. On a computer it shows an app-sized viewport, with review controls outside the app. On a phone it fills the available screen. A separate wide companion link remains available.

- Home leads with the children, Add a memory and a recent moment. Compact next-handover and request shortcuts remain visible. Child profiles link directly to their filtered memories.
- Calendar opens a seven-day selector and a selected-day agenda; Week shows grouped daily agendas. The phone no longer depends on dragging a desktop calendar sideways. Friday keeps 17:00 as agreed and routes the 18:00 proposal to Requests.
- Primary actions use large, rounded, yellow buttons with visible verbs. Secondary actions use a light surface and border. This hierarchy also applies to request responses and forms.
- Messages has a scrollable conversation and a composer that stays in view in the app preview. Main tabs remain accessible.
- All four memory layouts keep their distinct structure, now using the same app header, labelled Add memory action, family filters and sheets. The M3 shelf remains the leading candidate.
- Requests, packing, child profiles, setup and settings use the same readable fields, rounded groups and button sizes.

The [BeNice screenshots](https://play.google.com/store/apps/details?id=com.benice.family&hl=en) informed grouped rows, prominent rounded actions and sheet hierarchy. NAAST keeps its own B3 colours, compositions and assets. The screenshots are a visual reference, not proof of usability; their expense and AI features are not imported into scope.

The HTML prototype communicates the intended native screens. It is not an installed app, and the current CSS kits do not become native components automatically. The app will use actual React Native views and platform APIs. No fake system status bar is presented as device behaviour.

## 2. Recommended implementation

**React Native + Expo + TypeScript, using Expo Router.** Start from a current supported template when implementation begins, commit its lockfile and use the Expo-compatible package versions. Use native stack/tab navigation, platform date/media pickers, native text inputs and accessibility APIs. Build a small B3 component set: Button, ScreenHeader, ChildFilter, GroupedList, RequestCard, MemoryCard and BottomSheet.

Expo documents a common project targeting iOS, Android and web, including platform-specific handling. That fits the phone-first product with a secondary web client; it does not guarantee every component or OS capability is identical across platforms. [Expo tutorial](https://docs.expo.dev/tutorial/introduction/).

Use a development build for native integration and physical-phone testing. Expo Go can help early visual iteration but is not the release artifact. Local iOS builds need Xcode; cloud builds are another route. No signing credentials, paid build service or app-store account has been configured for this repository. [Expo development builds](https://docs.expo.dev/develop/development-builds/introduction/).

For the first backend, **managed PostgreSQL with Supabase Auth/storage is the recommended candidate**, subject to the existing access/media spike. Keep domain transitions in reviewed server-side functions/services. Database row-level policies enforce family access; request acceptance must atomically check membership, request state and affected care version, update the care block and write history. Do not let the native app directly patch agreement state. [Supabase row-level security](https://supabase.com/docs/guides/database/postgres/row-level-security), [database functions](https://supabase.com/docs/guides/database/functions).

Use one backend and one authoritative effective-plan model. Share TypeScript domain contracts and design tokens across mobile and web; platform components can differ. The native application must not depend on browser DOM, CSS frameworks or localStorage. Use appropriate protected session storage and validate invitations/auth return links on the receiving device.

Native push is now a launch delivery workstream alongside in-app notifications and email fallback. Keep the existing quiet-hour and privacy rules. Permission denial must not block normal app use; lock-screen payloads default to generic text. Test foreground, background, app-closed and signed-out behaviour with physical devices. [Expo notifications](https://docs.expo.dev/versions/latest/sdk/notifications/).

## 3. Start now with one complete slice

We have enough direction to begin the foundation. We do not need another full visual exploration before testing shared data. M1/M2/M4 alternatives can remain in the review gallery while the app uses the shared memory record contract and M3 as its temporary presentation.

**First milestone: add a child, save a photo/text memory, close the app and find it again on that child’s timeline.** Then prove safe shared coordination with the two-parent care-change loop. This sequence tests the commercial centre early.

1. Review the bounded [contract draft v0.1](15-first-slice-contracts.md), encode shared schemas/fixtures and create a Git repository before parallel edits. Keep the static review in `figmaish_pages/`; proposed production folders are `apps/mobile/`, `packages/contracts/`, `packages/design-tokens/` and `supabase/`. They have not been scaffolded by this visual task.
2. Build the native Home, Calendar, Memories, Messages and More shell with B3 primitives and explicit loading/empty/error states. Use M3 provisionally; do not implement all four layouts in production.
3. Add authentication/recovery, scoped family membership and a child profile. Implement text-only and photo-only capture without a mandatory title, child filtering and reopen-after-restart. Start with solo/private records; implement the disclosure/invitation contract before connecting another parent.
4. Prove unrelated-family denial, private/shared visibility, upload recovery, duplicate-create handling and author-only editing/deletion. An uploaded object or local toast alone is not a successfully saved memory. Use fictional records until access isolation is proven.
5. Next implement one already-confirmed dated care block and a proposal from 17:00 to 18:00. The recipient explicitly accepts/declines; server acceptance atomically changes the plan and writes history. Both sessions/restart show the result. Duplicate/stale/expired/wrong-actor responses cannot corrupt it.
6. Produce an installable development build and demonstrate both loops on a physical iPhone, plus Android if included in the pilot. Browser checks are supplementary.

**Definition of done:** persistent child/memory and two-parent request flows, repeatable migrations/seeds, focused access/concurrency/recovery tests, documented setup and a development build tested on the chosen phone platform. Each loop is an integration checkpoint; neither alone is the full launch MVP.

After these slices, broaden recurrence/holiday planning, questions and packing, then complete bounded clips, memory lifecycle/export and calendar portability. Run real-phone photo/video format research early alongside the first slice. Export/access design precedes real family data; public launch follows all acceptance gates. The [intuitiveness review](14-intuitiveness-review.md) includes the small parent task test to run alongside this work.

## 4. Contracts to settle before parallel work

| Contract | Required boundary |
| --- | --- |
| Actor/context | Server derives authenticated actor and family membership; client-supplied family IDs never grant access. |
| Care block | Stable ID, child IDs, start/end instants, family timezone, agreed version. Display local dates; store unambiguous instants. |
| Proposal | Request ID, expected care version, proposed values, author, pending state, expiry, idempotency key. |
| Response | Request ID/version and explicit action. Acceptance is one transaction; conflict is a distinct result with the current state. |
| Client states | Loading, ready, submitting, accepted, declined, expired, conflict, offline/retry. A cached view cannot imply a write succeeded. |
| Media | A memory references a typed asset with processing state. Poster/playback/export permissions follow the memory, not a public URL. |
| Notifications | Server event/outbox after a committed transition; minimal push payload; refetch on open. |

The [first-slice contract draft](15-first-slice-contracts.md) now specifies proposed routes, records, errors, media states and acceptance fixtures. Review and encode it as the first implementation artifact. Do not have separate sessions invent different auth, status names or database models.

## 5. Using more AI sessions

Start with **one lead session for the scaffold and contracts**, then at most **two implementation sessions in parallel**. Keep an independent review session available after the first integration. More simultaneous builders before the interfaces exist will mostly create reconciliation work.

| Session | Owns | Avoid editing | Completion evidence |
| --- | --- | --- | --- |
| Lead / integration | Scope decisions, shared contracts, root configuration, dependency versions, integration | Unreviewed live production data | Versioned contracts, running scaffold, an integrated slice |
| Backend | Migrations, access policies, memory/media lifecycle, request transitions, audit/outbox and focused tests | App navigation and visual components | Isolation, double-submit, stale-version and restart-persistence tests |
| Native app | Screen primitives, navigation, auth UI, child/memory capture and request flow against the agreed API | Database migrations or shared contracts without coordination | Typecheck, supported-device interaction evidence, real API errors handled |
| Review (after integration) | Read-only code review and focused regression checks | Product scope expansion | Reproducible findings, especially access, conflicts, device and keyboard behaviour |

Use separate Git worktrees/branches per builder. One lead owns the shared contracts and lockfile; changes to them must be communicated before implementation continues. Merge one coherent slice and run integration checks before starting more features. Do not run multiple agents modifying the same checkout independently. No additional sessions were launched during this visual pass.

Ready-to-use session briefs:

**Lead session**

> Read docs/10-final-mvp-scope.md, docs/13-native-app-and-kickoff.md and docs/15-first-slice-contracts.md. Create the Expo/TypeScript native scaffold and versioned contracts for the child/memory slice and subsequent care-change loop. Preserve the static review. Use B3, with M3 as the provisional memory presentation. Document what runs locally and what requires a device/signing account. Do not provision paid services or publish an app. Hand off stable API contracts and folder ownership before starting parallel builders.

**Backend session, after the lead has created the contracts**

> Implement the first-slice family membership, child/memory persistence, private media and subsequent care block/request transition against the agreed contracts. Own supabase/ and backend tests. Accepting must validate the actor, pending state and care version and atomically write the plan and history. Prove unrelated-family denial, duplicate submission, stale acceptance and persistence. Do not change mobile UI or silently broaden scope. Return migration/setup steps and test evidence.

**Native app session, after contracts and scaffold exist**

> Implement the B3 app shell, child/memory capture/revisit and subsequent care-change flow in apps/mobile/ using the shared contracts/tokens. Use native controls and the phone review as reference. Show loading, pending, accepted, declined, conflict and retry states. Keep server state authoritative. Do not change database schemas or invent endpoint shapes. Verify on the available device/simulator and report any physical-device limitation explicitly.

These briefs do not authorize sending messages to the cofounder, purchasing services or public store submission.

## 6. Estimates and release gates

The previous 70–110 days before reserve / roughly 90–140 with reserve estimated the web-first implementation including small clips. **That is not a current quote for the native-first delivery.** Backend/domain allowances remain useful inputs, but native UI, session/link handling, push, device/media integration, signing/distribution and platform QA need a revised task breakdown. Avoid simply adding a complete second UI budget: some web work is being replaced, not duplicated.

Re-estimate after the scaffold/device spike and the child/memory and request loops. The first milestone is deliberately much smaller than the launch scope; it should produce an installable internal build before committing to a full release date. Staffing, rates, platform coverage and provider selection remain open.

Suggested gates: working development build → first persisted two-parent loop → internal feature-complete build → physical-device/access/recovery review → 3–5-family pilot → approximately 20 families → public launch preparation. Use TestFlight for an iOS beta when account/signing and the build are ready; it is a distribution step with its own setup and review conditions. [Apple TestFlight](https://developer.apple.com/testflight/).

The current workspace has the static design review and planning documents. There is no production backend or installed native build yet. This plan makes the next implementation session concrete without claiming those systems already exist.