Mobile Developer — Product Scanner & Ingredient Transparency App (iOS + Android)

OVERVIEW We're building a consumer mobile app for barcode-based product scanning, text-based product search, ingredient transparency, and healthier product discovery. Think of it as a US/EU-focused product in the same category as Yuka, with a scoring methodology modeled closely on Yuka's published approach. We're looking for a full-stack developer to build the mobile app (iOS and Android, launching simultaneously), backend, and internal admin dashboard end-to-end. UI/UX designs are already complete in Figma — the developer implements, not designs. This is a production app, not a prototype. We need clean, maintainable code we can build on for years. SCOPE AT LAUNCH (v1) Mobile App (iOS + Android) Cross-platform implementation preferred (React Native or Flutter) to ship both platforms within budget and timeline. If you have a strong argument for native development within the budget, we're open to hearing it. Two primary ways to find a product — barcode scan and text search. Both must work reliably from day one: - Barcode scanning (camera-based), supporting UPC-A (US retail), EAN-13 (EU retail), and EAN-8 - Text search by product name or brand — typo-tolerant, fast on millions of records Other mobile features: - Product detail screens with pre-computed score, ingredient breakdown, and explanation - User history, favorites, and scan log - "Better alternatives" recommendations (same subcategory, higher score — see Recommendation Logic below) - Account creation and sign-in (Sign in with Apple, Google Sign-In; anonymous scanning allowed, account required for history and subscription) - Freemium subscription flow via Apple In-App Purchase on iOS and Google Play Billing on Android, with server-side receipt validation for both - Submission flow for missing products: capture barcode, cover photo, and ingredients photo Designs are complete in Figma and will be provided for both platforms. Subscription Tiers Free: Limited number of scans per month (exact number TBD, propose a starting value based on your experience). Basic product detail view only. Paid: Unlimited scans, full "better alternatives" recommendations, full scan history, favorites. Backend must implement feature-gating so tiers can be adjusted without app updates. Backend Core services: - Product database with pre-computed scores for food and cosmetics, indexed for both barcode lookup (exact match) and full-text product-name search - REST or GraphQL APIs for the mobile app and admin dashboard - Search infrastructure (Algolia, Meilisearch, Typesense, or Elasticsearch) for text search — not raw SQL queries. Barcode lookup should be a fast direct-indexed query. - Recommendations service for "better alternatives" (see Recommendation Logic below) - Image storage and CDN delivery (S3 + CloudFront, Firebase Storage, or Supabase Storage with CDN) - User submission queue with OCR pipeline for extracting ingredient text from uploaded photos (Google Cloud Vision, AWS Textract, or equivalent) - Receipt validation for Apple IAP and Google Play Billing - Transactional email service (SendGrid, Postmark, Resend, or equivalent) for account emails - Basic analytics tracking for scans, searches, views (propose a tool: Mixpanel, PostHog, Amplitude, or similar) - Background jobs for re-scoring when our methodology updates Infrastructure and operations: - Separate development, staging, and production environments - Automated daily database backups with documented restore procedure - Error tracking (Sentry or equivalent) - Uptime monitoring with email/SMS alerts (UptimeRobot, BetterStack, or equivalent) - API rate limiting to protect against abuse and enforce tier limits - API versioning strategy so older app versions on users' phones keep working after future updates - Secrets management (environment variables, not hardcoded keys) Compliance: - GDPR-compliant user data export endpoint - GDPR-compliant account deletion endpoint (right to be forgotten) - Minimal PII collection, documented data retention policy Hosting should be set up in our cloud account (AWS, Firebase, or Supabase), not the developer's. Propose your own stack based on what you'll actually ship fastest. Recommendation Logic "Better alternatives" should suggest products that are: 1. In the same product subcategory (for example, a granola bar should surface other granola bars, not all snacks) 2. Score higher than the scanned product 3. Realistically available to the user's market (US or EU) The approach does not need to be machine-learning-based for v1. A well-designed rules-based system with good category matching is acceptable. Please describe your intended approach in your application. Admin Dashboard (Web) - Review queue for user-submitted products - Edit and approve extracted ingredient data before products go live - Manual product editing and record management - Submission status monitoring - Basic operational metrics (submission backlog, approval rate, user growth) - Ability to adjust subscription tier limits (for example, change the free-tier scan cap) without a code deploy Simple internal tool. React, Next.js, or equivalent. No public-facing polish required. Scoring Methodology Our scoring will follow the same methodology Yuka publicly uses: Food: approximately 60% Nutri-Score (public EU-government algorithm) + approximately 30% additive risk scoring (based on published E-number and food-additive classifications) + approximately 10% organic bonus. Cosmetics: Ingredient hazard-based scoring using public ingredient databases (INCI, CosIng, and similar hazard classifications). Scoring is computed offline and stored in the database. The mobile app only reads scores. The scoring engine should be modular so the formulas can be tweaked over time without app updates. Out of Scope for v1 - User reviews, comments, or community features - Push notifications beyond transactional subscription receipts - Non-English languages at launch (copy should be stored in a way that allows localization later) - Loyalty programs, social sharing, affiliate links DATA STRATEGY (Required in Application) This is the hardest part of the project and the biggest make-or-break for the app's usefulness. If your product database is sparse or outdated, the app is useless no matter how polished it looks. We expect your application to address the following explicitly: 1. Source mix. Which data sources will you use and in what priority? (Open Food Facts, Open Beauty Facts, USDA, retailer websites, brand websites, paid databases like Syndigo or Label Insight, etc.) For each, what's the legal status (open license, scraped, licensed)? 2. Coverage target. What percentage of typical US and EU supermarket products do you expect to cover at launch? How did you arrive at that estimate? 3. Data ingestion pipeline. How is data imported, cleaned, deduplicated, and normalized into our schema? 4. Conflict resolution. When two sources disagree on the same product, how do you decide what's correct? 5. Refresh cadence. How often is data re-pulled to catch reformulations, new products, and removed products? 6. Images. How do product images get acquired and stored? What's your plan for products where no licensed image is available? 7. Missing products. Beyond the user-submission workflow already in scope, what's the process when a scanned product isn't in the database? Applications that skip this section or answer it vaguely will not be considered. MARKETS Launch markets are the United States and the European Union. This means: - GDPR-compliant data handling (minimal PII, clear consent, data export and deletion) - US privacy considerations (CCPA) - App Store and Google Play availability in both regions - Product data coverage sourced from databases covering both markets WHAT WE'RE LOOKING FOR - Demonstrated mobile experience — real apps in the App Store and Google Play, not demos or portfolio fillers (please include live store links for both platforms) - Solid backend experience with one of: Node.js, Python, Firebase, or Supabase - Experience with barcode scanning, image upload pipelines, and OCR - Experience shipping consumer apps with in-app subscription billing on both iOS and Android - Experience with data ingestion pipelines or product catalogs at scale - Clear, professional async communication in English - Comfort working from Figma designs - Ability to make architectural decisions independently and follow through to store launch without hand-holding QUALITY BAR - Critical-path automated tests required for: subscription and payment flow, barcode scan and lookup, score calculation, user submission flow - README documenting how to run the project locally and deploy it - Brief operations runbook (how to deploy, how to restart services, how to restore a database backup, how to rotate API keys) - API documentation for the mobile app's backend endpoints - Clean, commented code — no dead files, no commented-out blocks, no obvious AI-generated boilerplate ENGAGEMENT DETAILS Project type: Fixed-scope initial build, paid in milestones. Start: ASAP. Budget and timeline: Please propose your own, based on the scope described above. CONTRACT TERMS (Non-Negotiable) These protect both sides and filter out low-effort applicants. Please only apply if you're comfortable with all of these: 1. IP ownership. All code, designs, and deliverables are work-for-hire, owned by us from the moment they are written. 2. Repository access. Code is pushed to our GitHub or GitLab repository weekly at minimum. We do not accept final-drop deliveries. 3. Accounts in our name. Hosting, database, domain, Apple Developer Program, Google Play Developer account, and any third-party services are set up in our accounts. 4. Milestone payments. No large upfront payments. Pay is tied to specific, testable deliverables (for example, "barcode scan and lookup working on TestFlight and Google Play internal test"). 5. Paid trial task. Before we sign the full contract, we'd like to commission a small paid test task so both sides can see if we work well together. 6. NDA. Signed before any design assets or methodology documents are shared. HOW TO APPLY Please include in your application: 1. App Store and Google Play links to 2–3 mobile apps you have personally shipped on both platforms (not just worked on — shipped). 2. Your recommended tech stack and why. 3. Your Data Strategy (all seven questions answered in the section above). 4. Your approach to: - The user submission, OCR, and admin review pipeline - The "better alternatives" recommendation logic 5. Your proposed milestone breakdown (milestones, deliverables, payment amount per milestone). 6. Your realistic timeline. Applications that are clearly copy-pasted, skip the Data Strategy section, or don't include live store links will not be read. Apply tot his job Apply To this Job