1. The Capstone Brief
Build a real, small mobile app — not a to-do list clone, something you'd actually want to use — that touches at least five of the following, spanning multiple phases of this course:
- Nested navigation with an auth-gated flow (Week 5)
- Persisted or synced state (Weeks 6, 9, 11)
- At least one device API — camera, location, or sensors (Weeks 7–8)
- A real backend integration via TanStack Query (Week 10)
- Push or local notifications (Weeks 14–15)
- A test suite covering at least the core flow (Weeks 16–17)
A native module (Week 12) is optional — worth including only if your idea genuinely needs one, per Week 13's own guidance against reaching for one unnecessarily.
2. Architecture & Planning
Before writing a single screen, spend real time on three artifacts — cheap to produce now, expensive to retrofit later:
- A screen map — every screen, and which navigator (stack/tab/drawer, nested how) it lives in.
- A data model — what's persisted where (AsyncStorage, SecureStore, SQLite, or synced through a backend) and why, per Week 9's storage-choice framework.
- A one-paragraph "definition of done" — what has to work, end to end, for this to count as shipped, distinct from features that would be nice but aren't required.
Set up the project's EAS build profiles (Week 19) and Jest/Detox scaffolding (Weeks 16–17) now, at the very start — retrofitting a test setup onto a finished app is measurably harder than building alongside it from day one.
3. Building the Core (Week 1 of 2)
With the plan in hand, this week's build target is the app's skeleton, working end to end on real (not mocked) data and real (not placeholder) screens:
- Navigation structure fully wired, including the auth-gated flow.
- Every core screen rendering real data — from a real or realistic backend, not hardcoded arrays.
- The chosen device/native API integrated and working on a real device.
- State persistence or sync working and verified across a force-quit and relaunch.
Notifications, the full test suite, performance tuning, and store submission are deliberately next week's work — resist polishing early; a complete, rough skeleton beats a beautifully polished single screen with three more left unbuilt.
4. End-of-Week Checkpoint
Before moving into Week 22, confirm honestly:
- Every screen in the screen map exists and navigates correctly, even if unstyled.
- The app runs from a fresh install through its core flow with no crashes.
- At least one device API and one persistence/sync mechanism are both genuinely working, not stubbed.
- You could, if forced to, demo this app to someone right now and have it hold together.
5. Hands-on Exercise
Plan and build your capstone's core (Week 1 of 2)
Produce the planning artifacts, then build the app's working skeleton.
Requirements:
- Write the screen map, data model, and definition-of-done paragraph described above before writing any screen code.
- Scaffold the project with EAS build profiles and a Jest/Detox setup in place from the start.
- Build full navigation (including an auth-gated flow) and every core screen, wired to real data.
- Integrate at least one device/native API and one persistence or sync mechanism, both verified working on a real device.
- Run through the end-of-week checkpoint above and address anything that fails it before Week 22.
If scoping feels overwhelming, cut features, not phases of the course — a smaller app that genuinely exercises five different weeks' worth of concepts end to end is a stronger capstone than an ambitious one that only shallowly touches each.
6. Knowledge Check
Four quick questions. Expand each to check your answer.
Q1
Why does the brief require touching at least five phases of the course rather than going deep on just one or two?
Why does the brief require touching at least five phases of the course rather than going deep on just one or two?
The capstone's purpose is demonstrating that the pieces genuinely compose — navigation, state, a device API, a backend, and testing all working together in one real app — which is a different (and more realistic) skill than mastering any single piece in isolation. A narrow, single-phase project wouldn't exercise that integration at all.
Q2
Why plan a screen map and data model before writing any screen code?
Why plan a screen map and data model before writing any screen code?
Both are cheap to change on paper and expensive to change once screens and navigators are already built around a wrong assumption — a data model discovered mid-build to be missing a needed field, or a navigation structure that turns out not to support a needed flow, both mean real rework. Planning them first surfaces those problems while they're still free to fix.
Q3
Why does this week's plan defer notifications, the full test suite, and store submission to Week 22?
Why does this week's plan defer notifications, the full test suite, and store submission to Week 22?
Those are polish, verification, and delivery — necessary, but only meaningful once there's a working core to test, notify about, and ship. Building the working skeleton first, and deliberately not polishing early, avoids the common trap of a beautifully finished single screen sitting next to three unbuilt ones.
Q4
What does the end-of-week checkpoint actually verify, and why check it now rather than at the end of Week 22?
What does the end-of-week checkpoint actually verify, and why check it now rather than at the end of Week 22?
It verifies the app's core is genuinely functional — not stubbed, not crash-prone, not missing a working device API or persistence mechanism — while there's still a full week left to fix anything that fails it. Discovering a broken core flow during Week 22's final testing and submission push, with no time left to recover, is exactly the failure mode this checkpoint exists to catch early.