Product: PackyTrace — a personal food companion: scan a product, know in seconds whether it fits your goals and profile, and use what you bought before it expires. Brands pay downstream for anonymized engagement insights. Horizon: 6 months, closing at the Startup Day pitch (June 24). PMLC: Adaptive.

1. Design purpose

PackyTrace is a new, greenfield product. Its first version is deliberately not the finished platform but a validation instrument: the thinnest software that proves real consumers (20–30) use it and come back — and, second, that this engagement produces insights brands will pay for. The architecture exists to support fast learning and cheap change — not scale. After the pivot from brand-first to consumer-first, the order of proof matters: consumer traction (≥50 accounts, ≥30% week-2 retention) is the headline; brand monetization (≥1 LOI/pilot) follows from it.

2. Primary functionality

Four flows carry the system, matching the MVP backlog in Stories; everything else builds on them.

  • Scan → resolve → "does this fit me": a consumer scans a GS1 QR; anonymous scans work with no login (Epic 1), and an optional account with a consent-gated health profile unlocks the personal verdict — Good for you / Be careful / Avoid — at the top of the result (Epics 2–3). The core value moment; it must land in seconds at the shelf.
  • Fridge / expiry tracking: one-tap save of scanned products, freshness-sorted inventory, expiry alerts, honest waste tracking (Epic 4). This is the second half of the value proposition — adherence and waste.
  • Multi-source data ingestion: pull and normalize product data from heterogeneous sources (Open Food Facts API + ≥1 real producer source via API, scraping, or manual upload — Condition of Satisfaction #4). Technically hardest; sits directly on our #1 technical risk.
  • Engagement → anonymized brand view: capture consumer engagement (scan→account conversion is the primary signal) and expose only anonymized aggregates with a minimum group size to a deliberately simple brand dashboard (Epics 5–6).

Cut, not deferred: gamification — points, rewards, lottery. Advisory feedback was unambiguous: value must come from the product itself. The architecture must not carry dormant hooks for it.

3. Quality attributes (in priority order)

  1. Integrability — new and changing data sources must plug in without rewrites. Our #1 technical risk (data access) lives here, so this leads.
  2. Privacy / GDPR by design — the MVP now stores Article 9 special-category health data (allergies, conditions, diet). Explicit consent before any health data exists, the anonymized-aggregates-only wall toward brands, and immediate, verifiable erasure (QAS-3) are built in, not bolted on. This rose in priority with the pivot: the personal verdict is the product, and it only works if people trust us with the profile that powers it.
  3. Consumer usability — the scan moment is the product, and the ≥30% week-2 retention target depends on it. This includes the scan-moment latency budget: verdict and first content in ≤1s, full passport in ≤3s, graceful degradation when sources fail (QAS-1, QAS-2). That is a usability requirement, not a scalability one.
  4. Modifiability — every two-week cycle reshapes the backlog (the pivot itself proved it); change must stay cheap.

Deliberately deprioritized: scalability and throughput performance. At ~50 consumers and a handful of brands, over-engineering here would waste our €500 budget and pull effort away from validation. The latency budget above is the exception, and it is bounded to the single-scan path.

4. Constraints (not ours to choose)

  • GDPR: health profiles require explicit, recorded consent (Article 9); brands receive anonymized aggregates only; deletion is immediate for the data of record and verifiable across services; a short written data/GDPR position is a deliverable of the MVP (Condition #5).
  • Regulatory context: EU DPP / ESPR and GS1 Digital Link QR codes. Since the pivot this is a tailwind, not a dependency: the consumer value works on today's data sources and gets stronger as DPP arrives.
  • Budget: ≤ €500 over 6 months, self-funded → free tiers, open source, managed services where cheapest; ops run in-house, kept lean.
  • Timeline: Startup Day (June 24) closes the project; the MVP must be live early enough before month 6 to accumulate the traction evidence (50 accounts, week-2 retention).
  • Mandated integration: Open Food Facts API + ≥1 producer source.
  • Team: part-time (~10 hrs/week per person); the architecture must be operable and evolvable at that effort level.

5. Architectural concerns

  • Source-adapter layer (headline decision): each data source is a plug-in behind one common interface — isolating our #1 technical risk and serving our #1 quality attribute. Per-adapter timeouts, retries and circuit breakers so one bad source never breaks a scan (QAS-2).
  • Overall structure: originally analyzed as a simple modular monolith; revised to independently deployed services from the start (ADR-007), with cost of change kept low through one-command compose, a single shared Postgres/Kafka, and uniform service layout.
  • Privacy wall: one clear seam separating consumer-identifiable data (especially the health profile) from brand-facing aggregates, with a minimum group size enforced at the aggregation pipeline. The same seam makes erasure tractable: ID-only references, so deletion is removing references, not hunting copies (QAS-3).
  • Tenancy seam (brand = tenant): every brand-owned record carries a tenant ID; a scan resolves the GTIN to its owning tenant; brand-to-brand isolation is enforced centrally at the query layer, not by per-query discipline. Onboarding brand N+1 is a data operation, not a code change (ADR-001).
  • Consumer identity, two-tier: anonymous scanning requires no requested identity or account, but receives a stable pseudonymous Visitor ID; an optional minimal account (email + password) gates personalization and links to that Visitor ID. The health profile is a separate, consent-gated object that can be deleted without deleting the account. Engagement tracking (scan→account conversion, retention) is built in from day one so the success criteria are measurable.
  • Local-first scan path: GS1 decoding on the phone, verdict and allergen check from locally held catalog + profile data, external sources streamed in progressively (QAS-1). The health-critical answer never waits on a third party.
  • Build-vs-buy: lean on managed auth, hosting, and database; build only what differentiates — the verdict, the fridge, the adapter layer, the privacy wall.
  • Operations: light logging and metrics — just enough to feed the two-week review and the traction numbers in the Conditions of Satisfaction.