CASE STUDY
B2B local food distribution platform: built from structured discovery, field operation POC to full production, as sole product owner.
One product, three live surfaces: producer app, restaurant catalogue, central admin.
THE PROBLEM
A two-sided market failure.
Local producers in Savoie had no professional channel to reach restaurant kitchens directly. Restaurants wanting local supply had no reliable ordering infrastructure, no real-time availability, no professional-grade offer. Every existing supply chain ran through a warehouse intermediary that captured margin and lost freshness. No digital infrastructure existed for direct B2B local food trade at scale.
DISCOVERY FIRST
45 days as a food wholesaler before writing a single spec.
The discovery phase ran through expert partners, field research on both sides of the supply chain, a 45 days operating as a food wholesaler, a start-up studio bootcamp,— all before writing a single spec.
- 1
DISCOVERY
Stock accuracy was the critical operational pain — producers couldn't reliably communicate real-time availability.
ARCHITECTURE DECISION
Real-time producer stock sync to the e-commerce layer became the core technical requirement.
- 2
DISCOVERY
Quantity and quality errors from producers created friction.
ARCHITECTURE DECISION
A mandatory preparation workflow with quantity confirmation and photo validation to ensure quality.
- 3
DISCOVERY
Payment had to wait for producer confirmation, not trigger on order placement.
ARCHITECTURE DECISION
Shopify Payments API integration, with payment release linked to confirmed quantities rather than order placement.
System Design — Four Stakeholder Journeys Mapped
Complete architecture designed from field discovery. Four actors, full pain-point analysis, automated workflow decisions — documented before building the production platform.
THE SOLUTION
A digital local wholesaler centralising producers' offers.
Three interconnected surfaces on one shared database, each serving a distinct actor with its own access level and automated workflow.
Producer dashboard — stock and product management
Producer App
Real-time stock management, order notifications, structured preparation workflow, quantity and photo confirmation.
Restaurant storefront — live catalogue and availability
Restaurant E-commerce
Browse 1,200+ product references from 25+ producers within 50km, real-time availability, delivery slot ordering, integrated Shopify Payments.
Central admin — catalogue, producers and order routing
Central Admin System
Auto-routes orders to the correct producers via the product-producer database link, monitors preparation, dispatches logistics routing. The logistics partner — the fourth stakeholder — is served by automated route emails, with human-in-the-loop override at every step.
ONE SHARED DATABASE
Three surfaces, four stakeholders, one source of truth.
Every screen above reads and writes the same records. Producer stock, restaurant availability, order state, payment release and logistics routing are one dataset — which is what makes the whole system behave as a single product rather than four disconnected tools.
The shared schema behind every surface.
KEY ARCHITECTURE DECISIONS
Five tools connected. One interconnected database. Four stakeholders.
FOUR STAKEHOLDERS
One shared database
THE PRODUCTION STACK
Lovable
Three user surfaces — front-end build and product
Supabase
Shared database — single source of truth for all actors
Shopify Payments
Payment API via virtual store mirror — cost-optimised B2B card processing
Resend
Automated email notifications — orders, confirmations, logistics routes
Notion
Operational knowledge base and internal documentation
Claude acted as architect during the build.
The right product designed for B2B local distribution
DECISION 1
One shared database for all three surfaces.
WHY
Real-time sync between producer stock and restaurant availability requires a single source of truth. Three separate databases would create sync delays that break the core user promise.
DECISION 2
Shopify Payments API via a virtual store mirrored to the database — not Stripe.
WHY
Stripe's card processing rates were significantly higher for B2B transactions. A virtual Shopify store mirrored to the database gave access to Shopify's payment infrastructure at lower rates while keeping full control of the ordering UX.
DECISION 3
Payment release linked to producer quantity confirmation, not order placement.
WHY
Field operation revealed that quantity discrepancies between ordered and delivered were the primary source of client disputes. Holding payment until the producer confirms actual quantity protects both the restaurant and the producer relationship.
DECISION 4
Human-in-the-loop at Central Admin, not full automation.
WHY
Local food supply has quality variability. Full automation with no checkpoint would propagate errors — wrong quantity, quality issue — straight through to the restaurant. The system orchestrates; humans retain control at the critical decision points.
FROM POC TO PRODUCTION
The field wrote the spec.
PHASE 1
Field POC — MVP
Airtable · Fillout · Make.com
Validated the commercial model in the field by operating as a local wholesaler with a 2-person team: from customer and producer discovery, onboarding and sourcing to order management, logistics, delivery and adoption. In 45 days, 3 clients and 8 producers generated €10.5K revenue and 1,000+ kg of local products delivered — validating the model before building the full platform.
WHAT THE FIELD CHANGED
The POC had no preparation workflow for producers. In practice, quantity errors and quality issues at collection created friction and disputes. The production platform added a mandatory, step-by-step producer preparation workflow — quantity confirmation, photo validation of product quality — before any payment could be released. AI image recognition for automated quality checking was designed into the workflow architecture for future implementation.
PHASE 2
Full production platform
Claude as architect · Lovable · Supabase · Shopify Payments · Resend · Notion
Dropped an initial technical partnership and rebuilt the full platform as a sole product owner using AI tools. Core requirements traced back to field observations — with key workflows added and refined throughout the activation phase based on real producer and restaurant usage in production.
WHAT I WOULD DO DIFFERENTLY
“Start with the Central Admin system first. It's the orchestration layer everything else depends on. By building the e-commerce and producer app first, I had to retrofit the routing logic. Starting from the middle — the coordination system — would have made the whole architecture more coherent from day one.”
RESULTS
What it delivered.
producers activated
restaurants onboarded
product references integrated
local products delivered
client retention
adoption
PLATFORM
- →4 stakeholders connected
- →5 tools integrated
- →1 centralised database
WHAT THIS PROVES
Three capabilities demonstrated.
Full lifecycle ownership.
From market research and business model validation, through solo platform build, to commercial activation, logistics integration, user training, and continuous iteration.
Solution architecture under real constraints.
Four stakeholders, five tools, one database, automated workflows — every architecture decision driven by specific operational pain discovered in the field.
Adoption, not just delivery.
100% independent platform adoption after training. Producers, restaurants, and the logistics partner using the system autonomously without support requests. That is what lasting adoption looks like.