Dishova Roadmap — From Test Builds to Public Launch

This roadmap captures what I’m actively working on in testing, the near-term fixes my testers have surfaced, and the prioritized feature plan that follows. It’s written so testers, early users, and contributors can see what I’ll do next and how I’ll validate each change.


High-level priorities (now → 90 days)

  1. Close high-impact tester bugs that block the user experience and conversion.
  2. Make the UI smoother and consistent across light/dark modes.
  3. Stabilize auth and profile flows (Google Sign-In, profile pic upload).
  4. Fix cloud permission issues and error handling.
  5. After core stability, deliver higher-value features: barcode scanning, nutrition per recipe/serving, food diary.
  6. Finish with polish: feature toggles, in-app feature request place, first-run walkthrough, and ADA compliance.

Immediate sprint — Blocker fixes (HIGH)

Objective: Fix the flows that currently break or confuse testers so the rest of the app can be evaluated reliably.

Tasks

  • Achievements page: make Upgrade / Premium button behave exactly like Collections page (reuse same upgrade flow).
  • Recipes page: Add recipe-by-URL import to the Add → action (match plus button at bottom behavior).
  • Color scheme: fix color contrast and clashes in both light and dark modes (create theme token map; swap problem colors).
  • Google Sign-In: diagnose and repair OAuth flow (SHA certs, Play Console OAuth client, redirect/intent handling).
  • Profile picture: add UI to upload/change profile picture and persist to cloud storage.
  • Collections page: investigate and fix “cloud firestore permissions denied” adjust security rules and/or auth state handling.
  • General: smooth UI micro-interactions (button disabled states, loading spinners, toasts).

Acceptance criteria (for each task)

  • Achievements upgrade button opens the same modal/flow, records the same analytics event, and the Premium state updates immediately on success.
  • Add recipe UI offers both Manual and Import by URL; imported recipes parse ingredients and create editable draft.
  • Theme tokens produce no failing contrast checks (WCAG AA) for primary text and actionable controls in both modes.
  • Google Sign-In succeeds for new and returning testers on Android devices (test with multiple accounts); logins persist.
  • Profile picture upload (camera & gallery) works, shows progress, and updates avatar in-app and on the server.
  • Collections no longer throws a Firestore permission error for authenticated users; relevant tests added to CI.

QA checklist (Immediate sprint)

  • Unit/widget tests added where possible (mock PurchaseController, mock recipe import parser).
  • Manual test matrix: signed-in user flows, offline/slow network, successful/failed purchases.
  • Test devices: at least one older Android device, pixel-level emulator, and a modern Android device.

Release plan

  • Implement on branch: fix/priority-blockers
  • PR with issue links and test steps
  • Internal test build (Play Internal Track) → 10–25 testers
  • Collect feedback 48–72 hours → patch if needed → expand to Closed testing

Sprint 2 — Stabilize & instrument (MEDIUM)

Objective: Improve analytics, error visibility, and UX polish.

Tasks

  • Add analytics funnels for upgrade clicks → purchase completion (track source: achievements, collections, planner).
  • Add a clear in-app fallback for purchases (open Play Store subscription page if in-app fails).
  • Improve all error messages and add “Send feedback” shortcut with auto-attached logs/screenshots.
  • Smooth animations and transitions; add skeleton loading states for slow network.
  • Fix edge-cases in recipe import (long titles, missing images).

Acceptance criteria

  • Events: upgrade_clicked, purchase_started, purchase_success, purchase_failed; source parameter present.
  • Error dialog present with “Send feedback” action that captures current screen and minimal logs.

Sprint 3 — Feature work (MEDIUM → LOW)

Objective: Build the next high-impact features requested by testers.

Planned features (priority order)

  1. Barcode scanning for fast inventory entry (camera-based scan; fallback manual entry)
  2. Nutritional information per recipe and per serving (integrate a nutrition API or compute from ingredient data)
  3. Food diary (log meals, link to planned recipes, track servings & calories)
  4. Feature toggles: ability to hide unused features (for testers and minimal-profile users)
  5. In-app “Submit feature request” placeholder and triage board (captures user text, screenshot, priority)

Acceptance criteria

  • Barcode scanning reads UPC codes and either matches product info or populates a manual add form.
  • Nutrition: show calories/macros per recipe and per serving with a toggle for viewing.
  • Food diary: create, edit, and view past entries (day view + week summary).
  • Feature toggles: admin (you) can enable/disable features via remote config or feature flagging service.

QA checklist

  • Test barcode scanning across 3 physical barcodes and 2 fake barcodes.
  • Validate nutrition numbers against sample ingredients (spot-check).
  • Diary UX: add/delete/edit entries and confirm sync across devices.

Backlog & final polish

  • Introductory walk-through for first-run (multi-step modal or coach marks).
  • ADA compliance audit and fixes (WCAG 2.1 AA: semantic labels, color contrast, TalkBack compatibility).
  • Add account settings: export my data / delete account flow.
  • Marketing & launch prep: Play Store listing copy, screenshots, press kit.
  • Post-launch telemetry dashboard: conversion, retention, crash rates.
  • iOS optimization and Apple store test/launch sequence.

Security, privacy & permissions

  • Fix Firestore rules to require auth for user data and only allow access to owner documents.
  • Confirm OAuth credentials set correctly in Play Console (SHA-1 / SHA-256).
  • Ensure stored images use Firebase Storage rules scoped to user UID.
  • Publish/update Privacy Policy & Data Safety for Play Console detailing Firebase usage and storage.

Testing, metrics & monitoring

Key metrics to monitor (pre and post-release)

  • Crash-free users (Crashlytics)
  • Upgrade conversion rate (click → purchase success)
  • Recipe import success rate
  • Google Sign-In success rate
  • Barcode scan success / fallback manual entry rate
  • Retention: 7-day active users after installation

Test plan summary

  • Internal build → 10–25 testers (focus on core flows)
  • Closed test → up to 500 testers (device variety)
  • Open testing → broader audience if all core KPIs look stable

Rollout & rollback

  • Staged rollout via Play Console (10% → 25% → 50% → 100%), monitoring metrics at each step
  • Rollback option: revert PR and push hotfix; if urgent, push a configuration flag to disable new flow