Work Breakdown Structure¶

Purpose¶

This Work Breakdown Structure (WBS) is the management-level view of the PackyTrace MVP / pre-event phase. It explains how the project work was grouped, planned and tracked without exposing every technical checklist item.

The detailed execution notes remain in tasks/plan.md and tasks/todo.md. This page is intended for project review: it shows the main work packages, their purpose, their status and how they support the Conditions of Satisfaction.


Phase covered	MVP / pre-event phase
Delivery model	Adaptive, sprint-based
Closing milestone	Startup Day, June 24, 2026
Tracking tools	Living documentation, ClickUp, weekly reviews, technical checklists

Status legend¶

Status	Meaning
Done	Completed enough for the MVP phase
Partial	Started or useful, but not complete enough to close as full scope
Open	Deferred to a later cycle

WBS summary¶

WBS	Work package	Main deliverable	Status
1.1	Foundations	Domain analysis, architecture, contracts, local platform and CI guardrails	Done
1.2	Consumer Thin Slice	Scan, profile, consent, personalized verdict and Fridge flow	Done
1.3	Data and Feature Extension	Open Food Facts integration and complete Shopping List flow	Done
1.4	Deployment and Living Documentation	Cloud application deployment and published documentation	Done
1.5	Future Backlog	UX improvements, discovery items and technical hardening	Partial

WBS tree¶

flowchart TD P["PackyTrace MVP / pre-event phase"] P --> F["1.1 Foundations"] P --> C["1.2 Consumer Thin Slice"] P --> D["1.3 Data and Feature Extension"] P --> L["1.4 Deployment and Living Documentation"] P --> B["1.5 Future Backlog"] F --> F1["Domain and requirements"] F --> F2["Architecture and contracts"] F --> F3["Local platform and CI"] C --> C1["Anonymous scan"] C --> C2["Account, session and consent"] C --> C3["Profile and personalized verdict"] C --> C4["Fridge and expiry tracking"] D --> D1["Open Food Facts"] D --> D2["Shopping List"] L --> L1["AWS application deployment"] L --> L2["Cloudflare documentation deployment"] B --> B1["UX improvements"] B --> B2["Product discovery"] B --> B3["Platform hardening"]

Work packages¶

1.1 Foundations¶

Status: Done

This work package created the base needed to manage and build the product without improvising. It included domain analysis, personas, user stories, journeys, bounded contexts, quality attributes, initial architecture decisions, service boundaries, API contracts and local development guardrails.

Why it mattered: the project started with a broad DPP opportunity. The foundation work reduced ambiguity and made it possible to decide what belonged in the MVP and what should remain future scope.

Main outputs:

domain and requirements documentation;
architecture and API documentation;
initial architecture decisions and quality scenarios;
local platform setup;
CI, documentation and contract checks.

1.2 Consumer Thin Slice¶

Status: Done

This was the central MVP work package. The goal was to build one coherent user journey: scan a product, resolve product information, optionally create an account, give consent, fill a profile, receive a personalized verdict and save the item in the Fridge.

Why it mattered: this work package validated the core product idea at software level. Instead of building many disconnected features, the team focused on one vertical slice that could be demonstrated end to end.

Main outputs:

anonymous scan flow;
GS1 Digital Link-oriented product resolution;
account, session and consent flow;
health profile and deterministic verdict;
Fridge flow for expiry and waste tracking;
scan-first web interface.

1.3 Data and Feature Extension¶

Status: Done

This work package extended the MVP beyond the seed catalog and delivered the next consumer loop. Open Food Facts was integrated as a realistic product-data fallback, while Shopping List was implemented end to end as a separate context and independently deployed service.

Why it mattered: real product data makes the demo more credible, but feature expansion had to remain controlled. Keeping Shopping List separate from Fridge added the feature without weakening bounded-context or data-ownership rules.

Main outputs:

Open Food Facts fallback and attribution;
provenance distinction between brand-owned and community-sourced data;
Shopping List context, event-sourced service and owned schema;
gateway routes, consumer UI and explicit Shopping List ↔ Fridge prompts.

1.4 Deployment and Living Documentation¶

Status: Done

This work package made the project externally reviewable. The application was prepared for cloud deployment, and the documentation was published as living documentation.

Why it mattered: Startup Day required more than internal code. The team needed a demonstrable platform, a published explanation of the project and a way to keep knowledge available to technical and non-technical members.

Main outputs:

AWS deployment approach;
production-oriented Docker Compose package;
public routing and TLS setup;
deployment runbook;
MkDocs documentation published through Cloudflare Pages;
documentation checks in the development workflow.

1.5 Future Backlog¶

Status: Partial

This work package contains useful work that was intentionally not treated as mandatory for the MVP closure. It includes UX polish, product-discovery ideas and platform-hardening items.

Why it mattered: the team had many ideas, but the MVP phase needed discipline. Keeping these items in a backlog allowed the team to preserve them without letting them expand the current scope.

Main backlog areas:

UX improvements for scan, consent, error states and internationalization;
product-discovery items such as compare flows, AI brief and contribution flows;
platform hardening around erasure, outbox reliability and SDK extraction.

Progress rollup¶

Work package	Status	Phase interpretation
Foundations	Done	Enough structure existed to plan and execute the MVP.
Consumer Thin Slice	Done	The main MVP journey was demonstrable.
Data and Feature Extension	Done	Real data fallback and the complete Shopping List flow were delivered.
Deployment and Living Documentation	Done	The project could be shown and reviewed externally.
Future Backlog	Partial	Valuable improvements existed, but were consciously deferred.

Scope decisions¶

The WBS also shows what the team chose not to complete during this phase. A full AI assistant, advanced analytics, community features, rewards and large-scale hardening were kept outside the committed MVP. This was not a failure of execution: it was a scope-control decision consistent with an adaptive project and a part-time team.

The phase could close because the foundations, consumer thin slice and deployment were complete enough to support Startup Day. The remaining work became input for the next cycle.

Maintenance¶

This WBS is a simplified management view. When the detailed technical checklist changes, tasks/todo.md should be updated first. This document should then be updated only when the change affects a work package, phase status or scope decision.