Documentation Index
Fetch the complete documentation index at: https://resources.devweekends.com/llms.txt
Use this file to discover all available pages before exploring further.
Project Overview
Estimated Time: 40+ hours | Difficulty: Advanced | Prerequisites: All previous modules
- Full-featured project management app
- Real-time collaboration
- Offline-first architecture
- Push notifications
- Analytics & monitoring
- CI/CD pipeline
TaskFlow - Project Management App
Phase 1: Project Setup (Week 1)
The first week is about building a solid foundation. Resist the urge to start coding features immediately — investing in proper project structure, TypeScript configuration, and tooling pays dividends for the remaining weeks. A common mistake is rushing to build the Kanban board on day one and then spending week three refactoring the navigation because the initial structure could not accommodate the auth flow.1.1 Initialize Project
1.2 Project Structure
1.3 TypeScript Configuration
Phase 2: Core Features (Week 2-3)
This phase builds the features users interact with directly. Start with authentication (it gates everything else), then project management, then the Kanban board. This order matters because each feature depends on the one before it. A useful mental model: think of this phase as building a house. Authentication is the front door — you need it before anything inside makes sense. The project list is the hallway. The Kanban board is the main living room where users spend most of their time.2.1 Authentication System
2.2 Project Management
2.3 Kanban Board Component
The Kanban board is the centerpiece of TaskFlow and the most technically challenging component. It combines horizontal scrolling (between columns), vertical scrolling (within columns), drag-and-drop gesture handling, and animated state transitions. Getting this right requires Reanimated for performant animations and Gesture Handler for responsive drag interactions.Phase 3: Advanced Features (Week 4-5)
This phase adds the features that separate a demo app from a production app: real-time collaboration, offline support, and push notifications. These are the hardest features to implement correctly because they involve distributed systems concerns — what happens when two users edit the same task simultaneously? What happens when a user makes changes offline and then reconnects? Do not aim for perfection here. Implement the simplest version that works, handle the most common edge cases, and document the known limitations. A “last writer wins” conflict resolution strategy is simpler than operational transforms and sufficient for most project management use cases. Conflict resolution decision matrix for TaskFlow:| Scenario | Strategy | Implementation |
|---|---|---|
| Two users edit different fields of the same task | Field-level merge — both edits survive | Server merges by field timestamp: if User A edits title and User B edits status, both changes apply |
| Two users edit the same field of the same task | Last writer wins (by server timestamp) | Server accepts the latest updatedAt; the other edit is silently overwritten |
| User edits a task offline that was deleted by another user | Delete wins | On sync, server returns 404; client removes the task from local store and shows “This task was deleted” |
| User creates a task offline with a UUID that collides | Client-generated UUIDs (v4) — collision probability is negligible | Use crypto.randomUUID() or uuid library; server rejects duplicates with 409 |
3.1 Real-time Sync with WebSocket
3.2 Offline Support
3.3 Push Notifications
Phase 4: Testing & Quality (Week 6)
Testing a capstone project is where you discover whether your architecture is actually testable. If your components are tightly coupled to navigation, global state, and network calls, writing tests becomes a slog of mock setup. If you followed the patterns from earlier modules (dependency injection via hooks, separated business logic, thin screen components), testing will be straightforward. Focus your testing effort where it matters most: auth flows (because bugs here lock users out), data mutations (because bugs here corrupt data), and offline sync (because bugs here lose user work). Do not spend time snapshot-testing every presentational component.4.1 Unit Tests
4.2 E2E Tests with Detox
Phase 5: Deployment (Week 7)
The final mile is often the hardest. Code signing, provisioning profiles, and store review guidelines will test your patience. The good news: with EAS Build, the most painful parts are handled for you. The bad news: you still need to understand what EAS is doing (creating certificates, managing profiles, submitting binaries) so you can debug when things go wrong — and they will. Start by deploying to internal testing tracks (TestFlight for iOS, Internal Testing track on Google Play). These do not require full store review and let your testers install builds within minutes. Only submit to production after your internal testers have verified the build on real devices.5.1 CI/CD Pipeline
5.2 EAS Configuration
Technology Selection Rationale
Before building, understand why each technology was chosen. In interviews and architecture reviews, the ability to articulate trade-offs behind tech choices matters more than the choices themselves.| Decision | Choice | Why This Over Alternatives |
|---|---|---|
| Framework | Expo (managed workflow) | Eliminates native build toolchain setup; EAS handles code signing; config plugins cover 95% of native customization needs |
| Navigation | Expo Router (file-based) | Type-safe routes from file structure; deep linking automatic; aligns with React Server Components direction |
| Client state | Zustand | Minimal boilerplate vs Redux; no provider nesting; works outside React components (useful for WebSocket handlers) |
| Server state | React Query | Caching, background refresh, optimistic updates built-in; separates server state from client state cleanly |
| Forms | React Hook Form + Zod | Uncontrolled by default (fewer re-renders); Zod schemas reusable for API validation; better TypeScript inference than Yup |
| Animations | Reanimated 3 | Runs on UI thread (no bridge crossing); worklets enable 60fps animations; gesture handler integration for drag-and-drop |
| Secure storage | expo-secure-store | iOS Keychain + Android Keystore backed; simple API; no native module linking required in Expo |
| Testing | Jest + RNTL + Detox | Jest for unit/hook tests; RNTL for behavioral component tests; Detox for E2E (real device, real gestures) |
| CI/CD | EAS Build + GitHub Actions | EAS for builds (no macOS runner needed); GitHub Actions for lint/test/deploy orchestration |
When You Might Choose Differently
These are not universal “best” choices — they are the best choices for this project’s constraints (Expo, small team, MVP timeline). Here is when the alternatives win:| If Your Constraint Is… | Consider Instead |
|---|---|
| Heavy custom native code (Bluetooth, AR, custom camera) | Bare React Native CLI workflow |
| Existing Redux codebase with 100+ reducers | Redux Toolkit + RTK Query (migration cost of switching is too high) |
| Exclusively GraphQL backend | Apollo Client (normalized cache is purpose-built for GraphQL) |
| Team has no React experience | Flutter (single language, less ecosystem fragmentation) |
| Need pixel-perfect iOS + separate Android UX | Two native apps (SwiftUI + Jetpack Compose) |
Architectural Decision Records
Throughout the capstone, document key decisions as lightweight ADRs (Architecture Decision Records). This practice is what separates a portfolio project from a tutorial copy-paste. When a hiring manager reviews your repo, these records demonstrate senior-level thinking.| Decision | Context | Options Considered | Chosen | Rationale |
|---|---|---|---|---|
| Conflict resolution strategy | Two users edit same task offline | Operational Transforms (OT), CRDTs, Last Writer Wins (LWW) | LWW with field-level granularity | OT/CRDTs add significant complexity; field-level LWW means simultaneous edits to different fields both survive; only same-field conflicts are lost |
| Offline queue structure | Pending mutations need ordering | Single FIFO queue, per-entity queues, event sourcing | Single FIFO queue | Simplest to implement; ordering guarantees are sufficient for task management; per-entity queues add complexity without proportional benefit |
| Auth token storage | Tokens must survive app restart | AsyncStorage, MMKV, Secure Store | Secure Store for tokens, AsyncStorage for non-sensitive user prefs | Tokens are high-value targets; Secure Store provides hardware-backed encryption; AsyncStorage is faster for non-sensitive data |
| WebSocket reconnection | Network transitions on mobile are frequent | Reconnect immediately, exponential backoff, user-initiated reconnect | Exponential backoff with jitter, max 5 attempts, then user prompt | Immediate reconnect causes thundering herd; infinite retry wastes battery; user prompt after max attempts is honest UX |
Evaluation Criteria
Code Quality (25%)
- TypeScript usage
- Clean architecture
- Code organization
- Best practices
Features (25%)
- Core functionality
- Advanced features
- Error handling
- Edge cases
Testing (20%)
- Unit test coverage
- Integration tests
- E2E tests
- Test quality
UX/Performance (15%)
- Smooth animations
- Fast load times
- Offline support
- Accessibility
DevOps (15%)
- CI/CD pipeline
- Environment management
- Monitoring setup
- Documentation
What Separates Good from Great
Most capstone submissions meet the functional requirements. Here is what distinguishes the top tier:| Area | Good (Meets Requirements) | Great (Exceeds Expectations) |
|---|---|---|
| Error handling | Try/catch around API calls; generic error messages | Error boundaries per feature; contextual error messages; retry with backoff; offline fallbacks |
| TypeScript | Types on props and state | Discriminated unions for state machines; branded types for IDs; strict mode with no any |
| Testing | 70% coverage; snapshot tests | Behavioral tests that survive refactors; factory functions for test data; separate test utilities |
| Offline | Queue mutations; replay on reconnect | Optimistic UI; conflict detection; partial sync; offline indicator in UI |
| Performance | App loads and scrolls smoothly | Performance budgets in CI; lazy loading for below-fold screens; preloading on navigation intent |
| Documentation | README with setup instructions | ADRs for key decisions; inline comments explaining why not what; API documentation |
Submission Requirements
- GitHub Repository with complete source code
- README.md with setup instructions
- Demo Video (5-10 minutes) showcasing features
- Architecture Document explaining design decisions
- Test Coverage Report (minimum 70%)
- Working CI/CD Pipeline
- Published App on TestFlight/Play Store Internal
Congratulations
You have completed the React Native Enterprise Mastery course. You now have the skills to build production-ready mobile applications used by millions of users. More importantly, you understand why things are built the way they are — not just the syntax, but the trade-offs, the failure modes, and the patterns that scale.Get Certified
Complete the certification exam to validate your skills