PeterPlan Audit Report

Category

Product Scope & MVP

Finding: The MVP is a specific, bounded list of five features (sign up, family profile, AI meal plan, shopping list, meal swap), paired with an explicit 'Not in the MVP' list (delivery integration, nutrition tracking, sharing) and a target of 200 users within three months of a March 2027 launch.

Reason/Impact: A bounded scope with a clear out-of-scope list and a measurable target reduces scope-creep risk and gives a concrete way to judge whether the MVP worked.

Recommendation: None

Category

Tech Stack & Build-vs-Buy

Finding: The plan states the chosen stack (Next.js, Supabase) and gives a reason: 'because I already know both.'

Reason/Impact: Even a brief rationale shows the choice was deliberate rather than arbitrary, which helps when revisiting the decision later.

Recommendation: None

Category

Commercial Model & Unit Economics

Finding: The free tier caps AI usage at one meal plan per week, which connects the per-use AI cost to the free pricing tier by limiting how often it can be used for free.

Reason/Impact: Capping the free tier's variable-cost feature limits the founder's exposure to unbounded AI costs from non-paying users.

Recommendation: None

Category

Launch & Operational Readiness

Finding: The plan gives a target launch timeframe (March 2027) and an expected volume (200 users in the first three months).

Reason/Impact: Having a rough timeframe and volume target helps size infrastructure and operational needs ahead of launch.

Recommendation: None

Category

Users, Access & Multi-Tenancy

Finding: The plan defers 'Sharing plans with other family members' to a later version, but never explicitly states who owns a family's data in the first version — whether each account belongs to one person, or the family profile is meant to be a shared unit.

Reason/Impact: Adding shared access later is one of the most expensive changes to retrofit once the data model, access rules, and billing are already built around single ownership. Deciding this now avoids a costly rebuild when sharing is added.

Recommendation: Write down explicitly who owns the account and its data in the first version — e.g. one parent's login owns the family profile, meal plans and shopping lists — even though sharing itself is deferred.

Example for your plan: In the first version, each account belongs to [one parent]; the family profile, meal plans and shopping lists are owned by that account. When family sharing is added later, we will decide how [other family members] gain access to the same data.

When to fix: Before you build (or build further)

Note: Not found in your plan.

Category

Data Model & Classification

Finding: The data model lists users, family profiles (including children's ages and allergies), meal plans and shopping lists, but nowhere states how long this data is kept or how it is deleted.

Reason/Impact: This data includes children's ages and health-relevant information (allergies), which is sensitive. Without a stated retention or erasure approach, sensitive data about children could be kept indefinitely with no plan for deleting it.

Recommendation: Write down how long family profile, meal plan and shopping list data is retained, and what happens to it when a user deletes their account.

Example for your plan: When a user deletes their account, their family profile, meal plans and shopping lists are permanently deleted within [30] days; allergy and children's-age data is never retained beyond this point.

When to fix: Before you build (or build further)

Note: Not found in your plan.

Category

API & Integration Design

Finding: The plan states the family profile — which includes children's ages and allergies — is sent to the OpenAI API, but nowhere describes how access to this integration is secured (e.g. whether the call happens server-side, how the API key is stored, or any auth on that connection).

Reason/Impact: Sending sensitive data to a third-party API without a stated security approach risks the API key or the data itself being exposed, especially if the call were ever made from the browser rather than a server.

Recommendation: State that the call to the OpenAI API happens server-side only, and where the API key is stored (e.g. a secret store, never in client code).

Example for your plan: The family profile is sent to the OpenAI API only from our server, never from the browser; the API key is stored in [our hosting provider's secret store] and is never exposed to the client.

When to fix: Before you build (or build further)

Note: Not found in your plan.

Category

AI / LLM Usage

Finding: The family profile, including children's ages and allergies, is sent to the OpenAI API, but the plan states nothing about whether this data is retained or used for model training by the provider.

Reason/Impact: Without a stated data-retention or training posture, sensitive data about children could be retained or used to train the provider's models without the family's knowledge or consent.

Recommendation: State the chosen provider's data-retention and training settings for this use case (e.g. opting out of training, or confirming data is not retained beyond the request).

Example for your plan: We use the OpenAI API with [training opted out / zero data retention] enabled for all requests that include family profile data.

When to fix: Before you build (or build further)

Note: Not found in your plan.

Category

AI / LLM Usage

Finding: The AI generates a weekly meal plan directly from the family profile, which includes stated allergies (e.g. nuts, dairy), but the plan does not describe any check that the generated meals actually respect those allergies before the plan is shown to the family.

Reason/Impact: If the model generates a meal containing a stated allergen, a family could act on it and a child could be harmed — this is exactly the kind of hard rule (a stated allergy) the plan itself sets, and an unchecked AI output risks breaking it with real safety consequences.

Recommendation: Add a check — automated or manual — that rejects or flags any generated meal containing an ingredient matching a stated allergy before the plan is shown to the user.

Example for your plan: Before a generated meal plan is shown to the user, we check each meal's ingredients against the family's stated allergies and [automatically remove / flag for regeneration] any meal that conflicts.

When to fix: Before you build (or build further)

Note: Not found in your plan.

Category

Problem & Validation

Finding: The plan names the problem and target user clearly, but the only validation mentioned is a plan to interview 15 parents and put up a waitlist before building — this is a planned step, not evidence collected yet.

Reason/Impact: Without real evidence (completed interviews, a live waitlist, an observed workaround) the founder risks building before confirming that parents feel this pain enough to want or pay for a solution.

Recommendation: Treat the planned interviews and waitlist as a real gate before further build investment — run them first, write down what you heard, and only proceed if demand is confirmed.

Example for your plan: We interviewed [number] parents and found [X]% described this as a weekly frustration; our waitlist has [number] sign-ups as of [date], which we treat as the minimum signal needed before building further.

When to fix: Before you build (or build further)

Category

Data Model & Classification

Finding: The plan names the stored entities (users, family profiles, meal plans, shopping lists) but does not identify which fields are personal or sensitive — for example, children's ages and allergies are listed as data items without being flagged as sensitive.

Reason/Impact: Without explicit classification, it's easy to treat sensitive fields the same as ordinary ones, which could lead to under-protecting the data that matters most, like allergy information.

Recommendation: Mark which stored fields are personal or sensitive (e.g. children's ages, allergies) in the data model, and note they need stricter handling than non-sensitive fields.

Example for your plan: Of the data we store, [children's ages] and [allergies] are classified as sensitive and handled with [stricter access controls / encryption at rest]; [email, shopping lists] are treated as standard personal data.

When to fix: Before you build (or build further)

Note: Not found in your plan.

Category

Security Fundamentals

Finding: The plan states that users sign up with email and password via Supabase, but does not state how each user is restricted to only their own data on the server or database side, how submitted data is validated server-side, where secret keys (such as the OpenAI API key) are stored, or how admin access is protected.

Reason/Impact: Naming an auth provider does not by itself prevent one user's data (including children's allergy information) from being accessible to another — those controls usually need to be explicitly configured and are not automatic.

Recommendation: Write down how each of these is handled: server-side checks that a user can only see their own family profile and plans; server-side validation of all submitted data; where the OpenAI key and other secrets are stored; and how admin access is protected.

Example for your plan: Supabase row-level security rules restrict each family profile, meal plan and shopping list to its owning account; all data submitted by users is validated on the server; the OpenAI API key is stored in [secret store], never in client code; admin access requires [MFA / a separate restricted login].

When to fix: Before you build (or build further)

Note: Not found in your plan.

Category

Scalability & Performance

Finding: Generating a weekly meal plan and shopping list via the OpenAI API is the product's core heavy/slow work, but the plan doesn't say whether this runs in the background (with the user told when it's ready) or while the user waits, or what the user sees during generation.

Reason/Impact: AI generation can take several seconds or longer; without a stated approach, the user experience during generation is undefined, and this choice affects how the front end and backend are built.

Recommendation: Decide and write down whether meal plan generation happens while the user waits (with a loading state) or in the background with a notification when ready, since this is the product's core feature and shapes how it's built.

Example for your plan: Meal plan generation takes up to [X] seconds; the user sees a [loading indicator / progress message] while waiting, and we will move to a background job with a notification if generation time increases significantly.

When to fix: Before you build (or build further)

Note: Not found in your plan.

Category

Compliance & Regulatory Classification

Finding: The plan states the target market is UK parents with children under 10, and stores children's ages and allergy data, but does not mention any data-protection regime or children's-data-specific rules (e.g. UK GDPR, the ICO's children's data guidance) that might apply.

Reason/Impact: Children's personal and health-adjacent data often carries rules beyond general data protection law; not identifying this early could mean building a data model or consent flow that doesn't meet those requirements.

Recommendation: Note that this product may fall under additional children's-data and health-adjacent rules, and flag this for review, even if the conclusion is that no extra rules apply.

Example for your plan: We are reviewing whether [UK GDPR's children's data provisions / the ICO's Children's code] apply to our handling of children's ages and allergy data, and will document our conclusion before launch.

When to fix: Before launch

Note: Not found in your plan.

Category

Commercial Model & Unit Economics

Finding: The premium tier offers 'unlimited plan regeneration and meal swaps' for a fixed £4.99/month, with no stated usage cap, cost ceiling, or cost-per-use estimate for the AI calls this involves.

Reason/Impact: If a small number of premium users regenerate plans very frequently, the AI cost per user could exceed the £4.99 they pay, eroding or reversing the margin on that tier.

Recommendation: Estimate the AI cost per regeneration and either set a soft usage cap for the premium tier or confirm the £4.99 price comfortably covers a reasonable worst-case usage pattern.

Example for your plan: We estimate the AI cost per regeneration at [£X]; premium users are soft-capped at [N] regenerations per month to keep our cost below the £4.99 price, after which [behaviour].

When to fix: Before launch

Note: Not found in your plan.

Category

Commercial Model & Unit Economics

Finding: The plan charges a recurring monthly subscription (£4.99/month) but says nothing about what happens when a payment fails, a user cancels, downgrades from premium to free, or asks for a refund.

Reason/Impact: Without this decided, users could lose access unexpectedly, keep paid features after cancelling, or raise disputes the founder hasn't planned a response to — all of which affect trust and revenue.

Recommendation: Write down what happens to a user's access and data when their payment fails, they cancel, downgrade, or request a refund.

Example for your plan: If a payment fails, the account reverts to the free tier after [grace period]; on cancellation, the user keeps premium features until the end of the paid period, then reverts to free; refund requests are handled [policy].

When to fix: Before launch

Note: Not found in your plan.

Category

Threat Model & Abuse Cases

Finding: The free tier gives one AI-generated meal plan per week at no cost — a feature with real per-use cost — but the plan does not mention any mitigation against a user creating multiple free accounts to get more free generations than intended.

Reason/Impact: Without a mitigation, the capped free tier's cost control could be bypassed by repeat sign-ups, undermining the cost assumptions built into the pricing model.

Recommendation: Decide how multiple free-account abuse will be limited or detected (e.g. email verification, device or payment-method checks) before launch.

Example for your plan: We limit free-tier abuse by [requiring email verification / limiting free accounts per device or payment method], and will monitor for unusual sign-up patterns after launch.

When to fix: Before launch

Note: Not found in your plan.

Category

Launch & Operational Readiness

Finding: The plan gives a launch timeframe and volume target and includes a paid tier, but says nothing about how users will get help or who will handle issues (e.g. a meal plan that ignores a stated allergy, or a billing problem).

Reason/Impact: Without a support plan, early paying users with real problems — especially safety-related ones like an allergy being missed — may have no clear way to get help, damaging trust at the most sensitive early stage.

Recommendation: Decide how users will contact support and who (even if just the founder) will handle issues, especially safety-related ones, in the first months after launch.

Example for your plan: Users can reach us via [support email / in-app form]; [founder name] handles all support requests directly during the first [3] months, with safety-related reports (e.g. allergy issues) prioritised within [X hours].

When to fix: Before launch

Note: Not found in your plan.

Category

Reliability & Recovery

Finding: The core feature (meal plan generation) depends on the OpenAI API, but the plan doesn't say what happens if that service is slow, down, or returns an unusable result.

Reason/Impact: Without a stated fallback, a failure in the AI provider could leave users with no meal plan and no clear message, right at the point they're trying to get value from the product.

Recommendation: Decide what happens if the OpenAI API fails or returns something unusable — e.g. a retry, a clear error message, or a fallback meal plan.

Example for your plan: If the OpenAI API fails or returns an unusable plan, we [retry once automatically / show the user a clear error and let them retry manually].

When to fix: Before launch

Note: Not found in your plan.

Category

Reliability & Recovery

Finding: The product stores family profiles, meal plans and shopping lists, and charges a recurring fee, but the plan says nothing about backups and restoring this data, or how the founder would find out if something broke.

Reason/Impact: Without backups, a database issue could permanently lose paying users' family profiles and history; without monitoring or alerts, the founder might not know about an outage until users complain.

Recommendation: State the backup approach for the database and how the founder will be alerted if the service goes down or errors spike.

Example for your plan: Our database is backed up [daily] with [X]-day retention via [provider]; we use [monitoring tool] to alert us if error rates spike or the service goes down.

When to fix: Before launch

Note: Not found in your plan.

Category

Build & Release Process — not stated

What this covers: how the product will be built and how changes are checked before they reach users.

What to consider: who or what writes the code (you, a developer, AI coding tools); automated tests for the main user journeys; someone or something reviewing the code, especially AI-written code; a test copy of the product to try changes on first; how you'd undo a change that breaks things.

Is it relevant to you? Yes for any product real people will use. It matters most when AI tools write much of the code, because they can break working features without noticing.

For your plan: The plan doesn't describe how code will be tested, reviewed, or released, and since this product generates AI meal plans against stated allergies, having some way to check changes before they reach users matters more than for a typical low-stakes app.

Note: Not found in your plan.