Item is not Placement
One item can appear in many menu contexts. Base price belongs to the item; contextual adjustments belong to placements; the menu price is calculated.
Product portfolio case study
How product architecture, canonical data, explicit AI boundaries, and evidence-led decisions shaped One 8 Eats from idea to pre-Beta design-partner validation.
The problem
Menus, websites, photos, pricing, locations, events, identity, and owner requests live across disconnected tools and formats. A small update becomes repetitive manual work, while inconsistent copies make it harder to know which version is real.
The thesis
The platform should not begin with another publishing surface. It should begin with a canonical restaurant record, clear ownership, and a review path that lets AI help without silently deciding what is true.
Product model
Three product decisions
One item can appear in many menu contexts. Base price belongs to the item; contextual adjustments belong to placements; the menu price is calculated.
A location may be operationally assigned without automatically becoming visible on a public website. Those are separate owner decisions.
AI output remains a proposal until an authorized owner approves it and deterministic services validate the commit.
What was built
Connected menus, items, placements, locations, groups, media, events, and identity.
Photo2Menu proposals and selected Mia-assisted flows that preserve owner control.
A server-rendered restaurant website plus pre-Beta presentation controls, with expanded composition work still in development.
How the work operates
Product direction, owner experience, architecture, specifications, scope decisions, and final UAT.
Bounded implementation, testing, diagnosis, fixes, and development delivery under the execution contract.
Code review and audits at an owner-defined scope, providing a separate check on implementation and evidence.
The separation is intentional: the product owner retains direction and acceptance, while AI systems operate inside explicit responsibilities rather than an undifferentiated “build it” loop.
Commercial validation
One restaurant design-partner deployment is implemented and under controlled validation. It provides evidence about owner workflows, restaurant structure, presentation needs, and where product assumptions need to change.
That is meaningful progress, but it is not represented as broad production adoption or general availability.
A bounded environment for validating product choices and operational fit.
Implemented and under controlled validationCurrent status and next milestone
Owner workspace, canonical structures, Photo2Menu proposals, selected Mia workflows, design-partner deployment, and a current server-rendered restaurant website.
Complete the Beta onboarding journey and advance the additional website composition and publication work without overstating future channels.
Vincent’s role
Vincent framed the business problem, defined the owner experience and trust boundary, established the canonical architecture, translated product decisions into bounded specifications, and retained final acceptance.
This case study demonstrates product strategy, AI-native workflow design, domain modeling, evidence-led prioritization, and multi-agent delivery governance—not just interface design.
More about the founder →