A new web application that mirrors the core MyFoodDoctor mobile experience, rebuilt for the browser. The mobile app keeps running exactly as it does today — this is an additional platform, not a replacement — with one key change: subscription billing on web moves from mobile app-store purchases to Stripe.
MyFoodDoctor already exists as a mobile app offering food diary tracking, personalized nutrition methods, e-learning courses, a food lexicon, and psychological eating assessments. This proposal covers bringing that same experience to the web — same features, same personalization engine, new platform. The web app will share the backend and data model already powering mobile, so user accounts, diary history, and progress carry over seamlessly regardless of which platform a user opens.
Importantly, this is additive: the mobile app is not being retired, rebuilt, or paused. It continues to serve existing users and app-store subscribers without interruption. The web app is a second front door into the same product — useful for users who prefer a browser, for corporate/insurance partners who want a link-based experience, and for prospective users evaluating MFD before installing anything. Both clients will call the same backend, so feature parity is maintained by design rather than by manual syncing.
All core sections of the mobile app, rebuilt as responsive web experiences.
Daily logging, meal categories, macros, water & exercise tracking, diary export.
Search, barcode lookup, AI photo analysis, favorites & custom meals. Voice input scoped as optional (browser mic support varies).
Personalized recommendations, activation & adherence tracking, progress view.
Chapter-based e-learning, quizzes, celebration screen, PDF certificate export.
Searchable food encyclopedia with recipe discovery and filtering.
Eating-behavior questionnaire that feeds personalization, ported as-is.
Weight & waist logging with trend charts.
Health intake form, profile management, insurance details.
Password, legal pages, GDPR-compliant account deletion.
App-store billing only works inside native apps, so the web app needs its own payment path. Stripe replaces it for the web subscription tier, while the ZPP one-time preventive purchase and coupon system carry over conceptually to Stripe Checkout as well.
Four phases, building outward from the shared backend so the web app stays in sync with mobile at every stage rather than diverging and needing to be reconciled later.
Set up the Next.js project, design system, and routing. Build authentication (login, registration, password reset) against the existing MFD backend. Stand up the API integration layer so mobile and web read/write the same user, diary, and profile data. Includes environment setup, CI/CD, and a deployable staging build.
Build the Food Diary, the logging methods (search, barcode, AI photo analysis, favorites, custom meals), the Lexicon and Recipes browser, weight/measurement tracking, and the profile & anamnesis flow. This is the largest phase since it covers the day-to-day features users touch most.
Implement the optimization Methods tab (evaluation flow, activation, target questions, progress view), the Psychogram questionnaire and result screen, and the full course engine — chapters, quizzes, chapter unlocking, celebration screen, and PDF certificate generation.
Integrate Stripe Checkout, Customer Portal, and webhooks for both the subscription and ZPP one-time purchase; migrate coupon codes to Stripe promotion codes; run cross-browser and access-control QA; then a staged/soft launch before general availability.
Next.js is the frontend framework of choice — it gives us server-rendered pages for fast first loads and good SEO on public/marketing-facing pages (useful for insurance and corporate landing pages), while still behaving like a standard React app for the logged-in product experience.
Things worth flagging up front while scoping this out.
No downtime, no re-release, no forced migration for existing mobile users. Web is launched as a parallel option.
Diary entries, weight logs, and course progress made on web appear on mobile and vice versa, since both read the same account.
Web updates ship instantly without app-store review, which is useful once the Stripe flow is live and needs quick fixes.
Browser microphone support is inconsistent across devices, so this logging method is nice-to-have rather than v1-critical.
A browser-based flow makes it easier to send ZPP or corporate-wellness signup links that don't require an app install first.
Access checks move to our backend rather than the device app store, so the same logic works no matter where a user paid.
Estimated at roughly 7 weeks end to end, run largely sequentially with some overlap possible between phases 02 and 03 once the API layer is stable.
| Phase | Focus | Estimate |
|---|---|---|
| 01 · Foundation | Next.js setup, design system, auth, backend/API wiring, staging environment | 1 weeks |
| 02 · Core Features | Diary, all 6 logging methods, lexicon, recipes, profile, weight tracking | 2 weeks |
| 03 · Personalization | Methods engine, evaluation flow, psychogram, courses, quizzes, certificates | 2 weeks |
| 04 · Billing & Launch | Stripe Checkout/Portal/webhooks, QA, staged rollout | 2 weeks |
| Total | 7 weeks |