Project Definition Statement

Where this document sits

In our scoping flow, work moves from Conditions of Satisfaction, to requirements, to a structured backlog, to the choice of a delivery model, and finally to the documents that carry the project forward: the Project Overview Statement and its expansions. This Project Definition Statement is that expansion. The Project Overview Statement says what we are doing and why in one page; this document adds the operational detail needed to plan and run the phase: scope boundaries, deliverables, roles, acceptance approach and the risks we carry forward.

Project

Name: PackyTrace Phase covered: MVP / pre-event phase Closing milestone: Startup Day, June 24, 2026 Delivery model: Adaptive (see PMLC Model)

Purpose

PackyTrace helps a defined consumer group, people aged roughly 20 to 30, decide whether a food product is coherent with their personal goals, and then manage what they bought so it is not wasted. The scan in the shop, or at home, becomes the moment when product data works for the person holding the product: does this fit who I am trying to become, and will I use it before it expires.

The project is also a startup validation effort. Consumer value comes first. Brand analytics and monetization are evaluated only after the consumer experience proves useful. This ordering is the central lesson of the pivot: the earlier brand-first framing was not felt by the people who would have to use it, so the project was reshaped around consumer adherence and waste reduction.

Scope of this phase

This phase delivers a demonstrable MVP platform and the validation evidence around it, not a complete commercial launch.

In scope:

  • anonymous product scan with no login required;
  • product resolution through the internal catalog and external sources such as Open Food Facts, plus at least one real producer source;
  • optional account, session and consent flow that unlocks personalization;
  • health profile and personalized "does this fit me" verdict;
  • Fridge flow for expiry tracking and waste reduction;
  • a deliberately simple brand view showing anonymized aggregates only, kept behind the privacy wall;
  • documented architecture, API contracts, deployment flow and CI guardrails;
  • a cloud-accessible platform link for external review;
  • Startup Day pitch and feedback capture.

Out of scope for this phase:

  • gamification, rewards and lotteries, removed from the MVP after the pivot;
  • a full AI assistant experience;
  • an advanced brand analytics dashboard;
  • a complete Shopping List user flow;
  • large-scale consumer traction;
  • a signed brand letter of intent or paid pilot at scale;
  • funding closure.

Deliverables

  • Project Overview Statement.
  • Conditions of Satisfaction.
  • This Project Definition Statement.
  • PMLC Model rationale.
  • Software sprint record.
  • Sprint plan and sprint checklist.
  • Meeting log covering weekly team coordination and mentor meetings.
  • Validation sessions log covering interviews and external feedback.
  • MVP platform link.
  • Startup Day materials and feedback notes.
  • Final Project Management report.
  • MVP closing audit.

Roles

  • Software architect / developer: domain and architecture translation, software planning, task breakdown, AI-agent coordination, implementation control and technical validation.
  • Product and research: feature research, product framing, interview synthesis and Design Thinking cycles.
  • Market and business model: market analysis, business model, company contact and pitch positioning.
  • Public image and entrepreneurship: website and presentation material, startup communication.
  • Sustainability and external relations: NGO and sustainability-related contacts.
  • Interviews and conferences: interview execution and public presentation.

The team works part-time, roughly 10 hours per week per person, with a weekly sync and a written team agreement, under a total spend ceiling of 500 euro.

Acceptance approach

This is phase acceptance, not final startup acceptance. The phase can be closed when:

  • the MVP flow is demonstrable through the online platform or a safe demo fallback;
  • the core project documents are complete enough to explain scope, success criteria and execution method;
  • the team can show what is done, what is partial and what remains for the next cycle;
  • Startup Day feedback is captured and used to decide the next priorities.

The project continues after Startup Day with user testing, brand validation and funding work, following the same adaptive flow.

Main risks carried forward

  • Consumers may not adopt the platform if the value is not immediate or the flow is too complex. This is now the primary risk, which is why consumer interviews come before new feature work.
  • Differentiation is unproven: Yuka shows people will scan spontaneously, so we must offer something it does not. The RAMI analysis exists to answer this in writing before building further.
  • Too much feature ideation can dilute the MVP, so scope is actively reduced each cycle.
  • AI agents increase delivery capacity but require strong architectural and contract control to stay safe.
  • Validation evidence is still limited, especially user testing at scale, a brand letter of intent or pilot, and funding.