Plantry — Product Requirements Document¶

Example PRD generated via Sharpener.dev, demonstrating the complete bmad-method 9-section PRD structure.

Plantry¶

Executive Summary¶

Vision¶

Build a mobile app that turns a single photo of a user's pantry or refrigerator into immediate, practical meal recommendations so users stop fretting over what to cook and can act in minutes.

Target users¶

• Primary: Working parents with school-age kids who need quick, family-friendly dinners on weeknights.
• Secondary: Single professionals or couples cooking on weeknights, and stay-at-home parents who want faster meal decisions.

Problem being solved¶

Users experience decision fatigue at mealtime and lack time to plan.

Manually typing ingredient lists is slow, error-prone, and breaks momentum; that friction causes skipped meals or takeout decisions.

How success feels for users¶

A user snaps a photo, sees several cookable recipes ranked for time and family-fit, and starts cooking within minutes — no typing, no second-guessing.

Key user outcomes¶

• Faster meal decisions on weeknights.
• Lower cognitive load at dinner time.
• Higher utilization of ingredients on hand (fewer trips to the store).

What Makes This Special¶

• Photo-first input — the core insight is removing manual entry: a single image becomes the canonical source of truth for available ingredients.
• Immediate, contextual recommendations — recipes are filtered and ranked by what can be cooked now with what's visible in the photo, prioritizing time-to-table and family suitability.
• UX wedge: camera-to-recipe flow — the instant, reliable "photo in -> recipes out" interaction collapses the hardest part of meal planning and creates a delightful, repeatable habit.
• Practical accuracy over novelty — prioritizing pragmatic recipe matches and cook time beats exotic suggestions; users choose predictability and speed on busy nights.

Project Classification¶

projectType: "mobile app"
domain: "general"
complexity: "medium"
projectContext: "greenfield"

Success Criteria¶

User Success¶

• Primary outcomes: Users feel fast relief and confidence when deciding what to cook from a single photo. This is measured by users starting to cook within a short time window and reporting that a recommended recipe was usable with no extra shopping.
• Key user moments: the "aha" is when a user snaps a photo and sees immediately actionable recipes that match only the visible ingredients and fit family/time constraints. Success is the user tapping "Start" or equivalent and beginning to cook without searching for missing items.

Business Success¶

• Early traction target: reach 5,000 weekly active users (WAU) by the end of month 3. This is the stated growth milestone for early market validation.
• Engagement & retention: track 7-day and 30-day return rates, plus weekly sessions per active user. These metrics indicate habit formation and product value. Exact percentage targets for retention should be defined with cohort data post-launch, but tracking must be in place from day one.
• Engagement depth: monitor WAU × average weekly sessions per active user as a leading indicator of sustained usage and virality potential.

Technical Success¶

• Recipe match quality: measurable match rate ≥ 70%, defined as the percentage of recommended recipes that users mark (or implicitly confirm by starting) as usable without needing to buy extra ingredients. This is the prime technical success signal.
• Time-to-action: median photo → start cooking ≤ 3 minutes as the target for a smooth camera-to-recipe flow. This measures perceived speed and convenience.
• Ingredient scope constraint: MVP will match recipes using only ingredients visible in the photo to set a strict, testable boundary for the matching model.
• MVP posture: prioritize match accuracy-first (meet the ≥70% match rate) even if initial time-to-action is higher; later iterations optimize latency and UI flow.

Measurable Outcomes¶

Product Scope¶

MVP - Minimum Viable Product¶

Must-haves:

• Photo-first capture flow (single-photo input) with streamlined camera UX.
• Recipe matching engine constrained to ingredients visible in the photo.
• Recipe ranking by time-to-table and family-fit filters.
• Clear start-cooking CTA and simple feedback capture (usable / not usable).
• Basic analytics to measure match rate, time-to-action, WAU, and retention cohorts.

MVP success criteria: recipe match rate ≥ 70% (primary acceptance). Time-to-action measurement in place; reducing median time is a priority post-accuracy threshold.

MVP tradeoff: accept longer time-to-action if it materially improves match accuracy during initial experiments.

Growth Features (Post-MVP)¶

• Optimize time-to-action toward median ≤ 3 minutes through UI and model improvements.
• Relax strict-visibility rules with optional pantry history or user-confirmed inferred ingredients to increase applicable recipe matches where appropriate.
• Personalization (taste/family preferences), saved pantry, smart grocery list export, and repeat-recipe suggestions to increase retention.
• A/B experimentation framework to test ranking heuristics and family-fit signals.

Vision (Future)¶

• Full meal-planning workflow across multiple meals and days, integrated grocery ordering, multi-photo or video-based pantry scans, and cross-device persistence.
• Community and social features for sharing family-friendly recipes and curated menus.
• External integrations and APIs for recipe partners and retail/listing partners.

User Journeys¶

1) Working parent - Primary success path (Happy path)¶

Persona: Mara, working parent with school-age kids, one hour until dinner and no plan.

Opening scene: Mara arrives home, wants dinner in an hour with minimal hassle. The app defaults to a camera-first entry but also surfaces a clear manual entry/last-used recipes shortcut.

Rising action: Mara takes a single photo of the pantry and fridge. The app uploads the image, displays a brief progress indicator and a privacy reminder about image handling, then opens the Suggestions screen with ranked recipes prioritized by time-to-table and family-fit.

Climax: A clear recipe appears that uses visible, high-confidence ingredients. Mara taps Start and follows concise step cards in cook mode.

Resolution: By mealtime the family is eating a home-cooked meal and Mara feels relieved and confident.

High-level screens and choices: Camera (default) → Suggestions (ranked, confidence visible) → Recipe Detail → Start Cooking → Feedback (usable / not usable).

2) Working parent - Edge case (missing ingredient or low-confidence detection)¶

Situation: Photo is cluttered or the app misses a key ingredient. Mara needs a fast, low-friction recovery so dinner still happens.

Rising action: Suggestions show low-confidence matches or recommend recipes that would require a store run. The UI highlights inferred items with confidence levels.

Climax: The app offers a single, minimal confirmation step: a compact Ingredient Confirmation modal that highlights the inferred item(s) and gives quick options — Confirm, Suggest Substitutes, or Manual Edit — without forcing a full re-scan.

Resolution: Mara confirms a substitute or selects an alternate quick recipe and begins cooking without leaving the house.

High-level screens and choices: Camera → Suggestions (low-confidence state) → Ingredient Confirmation modal (Confirm / Substitute / Edit) → Revised Suggestions → Recipe Detail → Start Cooking.

3) Secondary user - Single professional / couple (quick solo cooking)¶

Persona: Alex, single professional cooking for one, values speed and minimal cleanup.

Opening scene: Alex takes a quick pantry photo after work or opens a "Quick Meals" shortcut, looking specifically for a 20-minute meal.

Rising action: Suggestions are ranked with a strong bias for short prep, minimal cleanup, and single-portion scaling; confidence and portion-size options are visible at glance.

Climax: Alex picks a recipe, taps Start, and follows a condensed cook mode with only essential steps and scaled ingredients.

Resolution: Meal is ready quickly and portion sizes avoid waste.

High-level screens and choices: Camera / Quick Shortcut → Suggestions (time and portion filters) → Recipe Detail (scale portions) → Start Cooking (compact mode).

4) Admin / Operations user¶

Persona: Ops manager who monitors model performance and content quality.

Opening scene: Ops receives daily alerts about drops in match-rate or spikes in low-confidence detections and opens an Admin Dashboard.

Rising action: They review analytics, sample low-confidence images (with user consent/retention rules applied), and inspect recipe metadata and tagging that contributed to mismatches.

Climax: Ops triages issues: tag corrections, content removals, or prioritized model retraining. Actions are traceable to session logs and versioned content edits.

Resolution: Match-rate improves and user complaints fall as content and model changes propagate.

High-level screens and choices: Admin Dashboard (analytics, image samples subject to privacy policy) → Content Editor → Model/Experiment Controls.

5) Support / Troubleshooting user¶

Persona: Customer support rep resolving a user report that a recommended recipe was unusable.

Opening scene: A user submits feedback "recipe unusable" with the original photo attached.

Rising action: Support pulls the session bundle (image, inferred ingredients with confidence, matched recipe, and the session timeline). Privacy flags are visible when retention limits apply.

Climax: Support offers a remediation path — in-app help, guidance, or escalation to Ops — with the case bundle attached so Ops can reproduce the issue.

Resolution: The issue is documented, the user is satisfied or refunded, and the case may trigger metadata fixes or training data changes.

High-level screens and choices: Support Console (ticket + image + session log + confidence metadata) → Case Actions (reply / escalate / refund) → Link to Ops.

6) API / Integration developer (if applicable)¶

Persona: Partner developer integrating the match API to submit images and receive recipe suggestions.

Opening scene: Dev registers for an API key and reads the docs for image submission payloads and expected response fields, including confidence and tag metadata.

Rising action: They POST image data (or image reference), receive ranked recipe matches and confidence scores, and debug using response logs and standard error codes.

Climax: Integration goes live and pushes usage metrics to a partner dashboard.

Resolution: The partner reliably surfaces recipe matches in their app and monitors quota and errors.

High-level screens and choices: Developer Portal → API Keys → Request/Response Logs → Webhooks / Monitoring.

Journey Requirements Summary¶

Capture & UX
- Camera-first capture flow as the default but explicit alternate entry points (manual ingredient entry, last-used recipes, Quick Meals shortcut) so users always have a fast path.
- Minimal friction: single-photo upload with progress and a short privacy notice; retry guidance and an inline, low-cost confirmation step when detection confidence is low.
- Suggestions screen that shows ranked recipes, visible confidence for inferred items, and quick filters (time, family-fit, portions).
- Compact Ingredient Confirmation UI for low-confidence matches that supports Confirm / Substitute / Edit quickly.
- Recipe Detail and Start Cooking flow with clear CTAs and a compact cook mode for quick recipes.
- Simple feedback capture (usable / not usable) tied to session logs and image references.

Model & Data
- Image processing pipeline that returns detected items with per-item confidence and substitution suggestions.
- Recipe matching engine that ranks by time-to-table and family-fit and can re-rank immediately after user confirmation.
- Robust logging of image, inferred items and confidence, session steps, and matched recipe metadata for reproducibility.

Support & Ops
- Admin dashboard for analytics, image sampling (subject to retention/privacy rules), and content moderation workflows.
- Support console with access to session bundles (image + inferred items + confidence + timeline) for fast troubleshooting.
- Content management tools to edit recipe metadata and remove or re-tag poor matches; all edits are versioned and linked to incidents.

Developer / Integrations
- API endpoints for image submission and recipe responses that include confidence and tag metadata; clear docs, auth, and logging.
- Developer portal with keys, docs, and request/response playground.

Product & Experience
- Explicit fallbacks and low-friction recovery when detection is low: confirmation modal, substitution suggestions, alternate quick recipes, and manual edit.
- Portion scaling and dietary filters to support different household sizes and preferences.
- Clear privacy controls and visible image retention rules presented at capture and accessible from support/ops.

Metrics surfaced by journeys
- Match-rate and usable feedback per session.
- Time-to-action (photo → start cooking) per user segment.
- Admin metrics: low-confidence incidents, support escalations, and content change impact.

Innovation¶

What's novel¶

• Vision-first ingredient detection as the primary wedge: treating a single photo as the canonical pantry/fridge state (no manual typing), enabled by a high-precision ingredient-recognition model tailored to messy, real-world kitchen imagery.
• Camera-to-recipe co-design: the model and UX are designed together so visual confidence drives immediate, actionable recipe suggestions that collapse decision time — not just "identify items," but reliably enable a user to start cooking from one photo.
• Strict visibility constraint (MVP posture): matching recipes only to ingredients seen in the image to create predictable, practical recommendations and reduce cognitive overhead or surprise shopping trips.

Core assumptions we must validate¶

• Vision accuracy is good enough in real-world conditions (lighting, occlusion, mixed packaging) to power usable recipe matches without manual correction.
• Users will prefer and adopt a camera-first flow over typing or barcode/manual pantry entry when the end-to-end experience is fast and reliable.
• Confidence signals from the vision model can reliably identify when to ask for a lightweight confirmation vs. show recipes directly (i.e., confidence calibration matters).
• Privacy and latency tradeoffs (on-device vs. cloud inference) will influence adoption — users accept image capture if handled transparently and safely.

Key technical challenges¶

• Real-world image variability: cluttered shelves, overlapping items, partially obscured labels, identical packaging across brands, and prepared food versus raw ingredients.
• Granularity and taxonomy: deciding detection targets (e.g., "tomato" vs. "canned tomatoes" vs. "tomato sauce") and supporting substitutions safely.
• False positives cost: an incorrectly detected item can yield unusable recipes and erode trust faster than missed detections.
• Quantity and usability: detecting presence is different from inferring sufficient quantity for a recipe; quantity estimation is noisy and optional for MVP.
• Latency and model size: balancing on-device inference for privacy and speed against accuracy limits and update cadence.
• Dataset scarcity: lack of large, labeled datasets of pantry/fridge photos across diverse households and cultural cuisines.

Validation experiments (what to test first and how)¶

• Offline vision benchmarks: build a representative test set of real pantry/fridge photos; measure per-item precision, recall, and confidence calibration across common ingredient classes and edge cases.
• Usability pilots: in-home or lab tests where participants use the camera flow to get recipes; collect binary usable/not-usable feedback and qualitative failure modes to link vision errors to recipe failures.
• Confidence thresholding experiments: tune when the system shows recipes directly vs. triggers the compact Ingredient Confirmation modal; measure impact on usable-recipe rate and time-to-action.
• Ablation tests: compare strict visible-only matching vs. allowing 1–2 inferred pantry items (from user history or probabilistic inference) to quantify tradeoffs between match rate and user surprise/shopping.
• On-device vs. cloud trials: pilot both deployment modes to measure latency, energy, privacy perception, and model accuracy tradeoffs.

Key validation signals to track (qualitative and quantitative):
- Per-item precision (to reduce false positives).
- Confidence calibration (probability that high-confidence detections are correct).
- Rate at which vision errors lead to "recipe unusable" feedback in pilots.
- User acceptance of photo capture and perceived privacy risk in real tests.

Design and UX implications¶

• Confidence-driven UX: surfaced per-item confidence, and a compact, low-friction Ingredient Confirmation modal for low-confidence detections (Confirm / Substitute / Edit) to avoid interrupting flow.
• Conservative matching for MVP: prefer omissions over false positives — better to miss an ingredient than falsely include one that breaks a recipe.
• Fast feedback loop: lightweight, in-app feedback (usable / not usable) tied to the original image to close the loop for model improvement.
• Progressive disclosure: show clear indicators when recipes require items of uncertain detection and offer quick substitutes or alternative recipes.

Tradeoffs and alternatives considered¶

• Strict visible-only matching (MVP) vs. inferred pantry augmentation: strict matching increases predictability; inferred augmentation can raise match rates but risks recommending recipes that require new shopping.
• On-device inference for privacy/latency vs. cloud for model capacity and update speed: on-device improves privacy and responsiveness; cloud enables larger models and faster iteration.
• Single-photo capture vs. multi-photo / short video scanning: single-photo minimizes friction; multi-photo improves coverage but increases complexity and user effort.
• Vision-only approach vs. hybrid inputs (barcode/OCR/manual): hybrid reduces vision risk at the cost of reintroducing input friction — a candidate post-MVP path.

Operational & privacy considerations¶

• Build consented image sampling and tooling for ops: enable safe, privacy-compliant image inspection and labeling (user opt-in for images used in training).
• Instrument robust logging (image metadata, detections with confidence, user feedback) to trace failures and prioritize retraining.
• Consider privacy-preserving strategies early (on-device inference, ephemeral uploads, automatic redaction) to increase user trust and reduce legal/ops burden.

How this innovation maps to the MVP posture¶

• Primary focus: deliver a high-precision, vision-first detection pipeline that produces conservative, high-confidence ingredient lists used to match recipes strictly to visible items.
• UX safeguards: confidence-driven confirmation and quick substitutes prevent small vision errors from breaking the core promise.
• Measurement-forward: early validation emphasizes linking vision errors to real user outcomes (usable recipes, time-to-action) so future investment prioritizes the parts with greatest user impact.

Domain¶

Mobile App Specific Requirements¶

Platform Support¶

• Decision: Native iOS (Swift) first, target iOS 16+ on iPhone 12 and newer for MVP to guarantee modern camera and network capabilities. Android will be a native port after iOS launch.
• Backend architecture: Cloud-only inference with server-side large models to prioritize accuracy and fast iteration. Design APIs and response contracts to be platform-agnostic to ease the Android port.
• Latency target: end-to-end photo→start median target 2–3 minutes for MVP; set server SLAs and client timeouts to meet this.

Device Capabilities¶

• Permissions required: Camera access and Photo Library access (allow selecting existing images). Capture UI must show explicit consent and the ephemeral-upload privacy notice at the point of capture.
• Image handling: Support HEIC and JPEG input; perform lightweight client-side resizing/compression before upload to limit bandwidth while preserving model accuracy.
• Hardware assumption: iPhone 12+ ensures consistent camera sensor and network characteristics; use this to size image preprocessing and expected upload latency.

Offline Strategy¶

• MVP posture: No offline inference support — image submission and recipe matching require network connectivity (cloud-only inference).
• Client UX requirements: clear offline state, retry queue for pending uploads, and a lightweight manual-ingredient entry fallback so users can continue when offline.
• Resilience: define conservative timeouts and exponential retry logic to avoid blocking the UI and to preserve the 2–3 minute experience goal where possible.

Push Notifications¶

• MVP decision: No push notifications in the MVP. Omit push infrastructure and avoid requesting notification permission on first release.
• Future note: defer engagement and reminder flows until after Android port and stabilization of core vision-match metrics.

Product Type¶

• Type: Native mobile app (iOS first, Android post-launch)
• Context: Greenfield development
• Complexity: Medium

Scope¶

MVP Features¶

Must-have (P0):
- Camera-first capture flow (single photo)
- Image upload pipeline with progress indicator
- Ingredient detection with per-item confidence
- Recipe matching constrained to visible ingredients
- Recipe ranking by time-to-table and family-fit
- Recipe detail view with step-by-step cook mode
- Start cooking CTA
- Usable / not usable feedback capture
- Analytics: match rate, time-to-action, WAU, retention cohorts
- Manual ingredient entry fallback (offline + edge case)
- Privacy notice at image capture

Should-have (P1):
- Ingredient Confirmation modal for low-confidence detections
- Substitution suggestions
- Quick filters (time, family-fit, portions)
- Portion scaling in recipe detail
- Offline state handling with retry queue

Won't-have (MVP):
- Push notifications
- Pantry history / persistent storage
- Personalization / taste preferences
- Grocery list export
- Social / community features
- Multi-photo capture
- Offline inference
- Android launch

Functional Requirements¶

Core Functionality¶

• FR-001: User can capture a single photo of their pantry or refrigerator using the device camera
• FR-002: User can select an existing photo from their photo library
• FR-003: System displays a brief progress indicator and privacy notice during image upload
• FR-004: System processes the image and returns a list of detected ingredients with per-item confidence scores
• FR-005: System matches detected ingredients against a recipe database and returns ranked recommendations
• FR-006: Recipes are ranked by time-to-table and family-fit filters
• FR-007: User can view recipe details including ingredients, steps, and cook time
• FR-008: User can tap "Start" to enter cook mode with step-by-step instructions
• FR-009: User can provide binary feedback (usable / not usable) on recommended recipes
• FR-010: System logs feedback tied to original image and session for model improvement
• FR-011: System displays an Ingredient Confirmation modal for low-confidence detections with options: Confirm / Suggest Substitutes / Manual Edit
• FR-012: User can manually enter ingredients as a fallback or to supplement photo input
• FR-013: App displays clear offline state and queue pending uploads when connectivity is unavailable
• FR-014: Analytics capture: match rate, time-to-action (photo → start cooking), WAU, and retention cohort data

Admin / Ops Features¶

• FR-015: Admin dashboard displays match-rate trends, low-confidence incident rates, and support escalations
• FR-016: Admin can sample images with user consent and inspect detection quality
• FR-017: Admin can edit recipe metadata (tags, cooking times, family-fit signals) with versioned audit log
• FR-018: Admin can remove or re-tag poor recipe matches; all edits are versioned and linked to incidents
• FR-019: Support console allows reps to pull session bundles (image + inferred items + confidence + timeline)

API / Integration Features¶

• FR-020: API endpoint accepts POST with image data (or image reference) and returns ranked recipe matches with confidence scores
• FR-021: API response includes confidence and tag metadata for all returned recipes
• FR-022: Developer portal provides API keys, documentation, and request/response playground
• FR-023: API logs request/response pairs for debugging; standard error codes returned on failure

Non-Functional Requirements¶

Performance¶

• NFR-001: Median end-to-end photo → recipe suggestions ≤ 10 seconds (network + processing)
• NFR-002: Median photo → start cooking ≤ 3 minutes (including user decision time)
• NFR-003: Recipe match rate ≥ 70% (measured as percentage of recommendations users mark usable)
• NFR-004: Server-side request timeouts set to prevent UI blocking (exponential retry up to 30s)

Security & Privacy¶

• NFR-005: Images are processed with explicit user consent at capture; privacy notice displayed
• NFR-006: Image retention rules are visible at capture and accessible from support/ops
• NFR-007: Consented image sampling for training requires explicit user opt-in
• NFR-008: On-device inference options considered early for privacy-preserving architecture
• NFR-009: API authentication via keys; developer portal access controlled

Scalability¶

• NFR-010: Backend architecture designed as platform-agnostic APIs to ease Android port
• NFR-011: Cloud-only inference enables fast model iteration without client updates

Accessibility¶

• NFR-012: Recipe detail and cook mode designed for glanceability (quick recipe steps on mobile)
• NFR-013: Portion scaling and dietary filters support users with different household sizes and preferences

Reliability¶

• NFR-014: Exponential retry logic with conservative timeouts to preserve UX under poor connectivity
• NFR-015: Offline state clearly communicated; pending uploads queued for later processing
• NFR-016: Robust session logging (image metadata, detections, user feedback) for reproducibility

This PRD was generated by sharpener using the bmad-method framework. It demonstrates the complete 9-section PRD structure and serves as a reference template for factory projects.