Build & Launch iOS App in 6–8 Weeks (React Native Expo + Firebase) — Photo-first cooking companion w/ classification + coaching + subscription Overview We’re building MØRNA, a photo-first cooking companion that instantly classifies what you’re cooking into a universal “control” system and delivers coaching. This is not a recipe app and not social. The core logic (“brain”) is already defined as a JSON config (tags, rules, scoring, coaching). We need a developer (or small team led by one owner) to build the full iOS v1 and ship to the App Store (TestFlight first), within 6–8 weeks. What “done” means in 6–8 weeks • TestFlight build ready for App Store submission. • Photo-first UX with assistive photo recognition plus strict fallback. • Deterministic rules engine driven by provided JSON config. • Tag chip editor, auto-labeling, and coaching cards. • Save/history/search with per-user cloud sync. • Sign in with Apple. • Subscription scaffolding + paywall gating. • Crash reporting + basic analytics events. • Clean repo handoff + setup docs. • Developer available for ongoing v2+ work on a retainer. Scope (v1) 1) Photo-first capture (no typing required) • App opens to camera. • Capture photo or select from library. • Upload to Firebase Storage and store reference. • Create a dish log entry. 2) Photo recognition (assistive, broad-category) From the photo, return a structured JSON output: • formatFamily: Soup/Stew/Baked/Handheld/Raw/Plated • body: Protein/Dough/Grain/Potato/Veg/Dairy/Fruit • signatureTexture: Crust/Moisture/Structure/Fresh • multiPhase: No / Yes (type) • confidence: 0–1 Hard fallback: if confidence is low, show 6 large buttons to select formatFamily (no typing). We are not trying to perfectly identify dish names in v1. 3) “Brain” integration (JSON rules engine) We provide a JSON config that defines: • Tag sets + caps • Conventions + decision rules • MØRNA class • SDS/MML scoring formulas • Coaching cards • Deterministic mappings Developer implements pure functions: • classify(inputs, config) → tags + mornaClass • computeScores(tags, config) → SDS/MML • getCoaching(mornaClass, scores, config) → cards • validate(tags, config) → messages • autoLabel(tags, scores, config) → standardized label Naming: users do not name dishes. App uses standardized global auto-labels only. 4) Tag editing UI • Chip selectors for ingredient/method/flavor/format/moment + mornaClass. • Enforce caps and required fields. • Live updates to mornaClass, SDS/MML, coaching as tags change. 5) Save + History + Search • Firestore persistence per user. • History list + entry detail view. • Search history (auto-label + filters). • Store userEdited boolean. • Optional post-cook failureMode (soggy/dry/burnt/bland/split/gummy). 6) Auth + Subscription • Sign in with Apple. • Subscription scaffolding with RevenueCat preferred (or native IAP). • Paywall + entitlement gating for premium features (final gating defined during build). 7) Production readiness • Crash reporting (Sentry or Firebase Crashlytics). • Basic analytics events (capture, classify, edit tags, save, subscription view/purchase). • App icon + basic splash screen (can be minimal). 6–8 Week Execution Plan Week 1: Foundation + Architecture • Expo project setup (TypeScript preferred). • Navigation scaffolding (3 core screens). • Firebase setup: Auth (Apple), Firestore, Storage. • Entry data model + create/read working. • Camera capture + upload working. • Deliverable: photo → saved entry pipeline. Week 2: Rules Engine + Tag UI (Brain → Body) • Load JSON config (local + remote config option). • Implement validate(), computeScores(), getCoaching(). • Build chip selector component with caps. • Tag screen with live updates. • Deliverable: manual tag + coaching + scores + save. Week 3: Classifier MVP + Auto-labeling • Implement classify(): deterministic mappings + conventions + composite detector. • Implement auto-label generator (remove user naming). • History list + detail view. • Search by auto-label. • Deliverable: prompts → tags → label → coaching → save → history. Week 4: Photo Recognition Integration + Fallback • Integrate photo recognition provider (vision model/API). • Return 4 fields + confidence. • Prefill prompts/tags automatically. • Low-confidence fallback UI. • Deliverable: photo → prefilled classification in 1 tap. Week 5: Subscription + Entitlements + QA Pass • Implement RevenueCat / IAP. • Paywall + premium feature gating. • QA edge cases: offline, upload failures, invalid tag states. • Deliverable: full v1 feature set working end-to-end. Week 6: TestFlight + Polish + Analytics • Crash reporting + analytics events. • UX polish (loading, errors, empty states). • TestFlight build + internal testing. • Fixes and stabilization. • Deliverable: TestFlight-ready app + App Store checklist. Weeks 7–8: Buffer / App Store Submission Support • App Store submission support (if needed). • Final polish and bug-fix buffer. • Minor UX improvements that don’t change scope. Required Developer Qualifications • Shipped mobile apps to App Store (links required). • Strong React Native Expo experience. • Firebase Auth/Firestore/Storage experience. • Experience with subscriptions (RevenueCat or native IAP). • Comfortable integrating a vision/LLM API with structured output + confidence + fallback. • Can commit to 6–8 week delivery with weekly milestones. Deliverables • TestFlight build + App Store submission-ready build. • Source code repo + setup documentation. • Firebase configuration instructions. • List of analytics events implemented. • 30 days bug-fix support post-delivery. • Availability for ongoing monthly retainer (v2–v5). Screening Questions (must answer) • Provide 2–3 App Store links for apps you shipped and your role in each. • Confirm you can deliver v1 in 6–8 weeks with the milestone plan above. • Describe your approach for photo → structured JSON output + confidence scoring + fallback. • Describe how you’ll implement the JSON brain as single source of truth (versioning, testing). • What subscription stack do you prefer (RevenueCat vs native) and why? • What’s your weekly availability and communication cadence? • Are you open to an ongoing retainer after launch? If yes, propose hours/month. Red Flags (we will reject) • Overpromising perfect dish recognition in v1. • Suggesting social features or recipe libraries. • No shipped apps. • No fallback plan if recognition confidence is low. • Not comfortable with subscriptions.