Skip to main content

Product overview

The problem​

Lucille is a restaurant group whose branches each order their own ingredients, and every supplier is reached through a different channel: email for Costco Business Center, a portal for Sysco, WhatsApp and SMS and phone calls for everything in between. The consequences are already felt:

  • Missed orders. A WhatsApp message is not a purchase order. Items get forgotten between the prep list and the supplier.
  • No consolidated visibility. The operations team cannot answer "what did we buy last week, and where" without asking every chef.
  • Manual overhead. Chefs spend hours a week channel-hopping instead of cooking.
  • Nothing is traceable. When a delivery is short there is no single record of who ordered what, when, and what was actually submitted to the vendor.

The solution​

Lucille Order Center presents chefs with one unified catalog of orderable ingredients. Supplier identity is deliberately absent from the chef-facing catalog: an item is an item. The chef adds items to a cart with quantities, submits once, and the system fans the order out to every supplier involved, in parallel, over each supplier's own channel.

If a supplier reports that a line item is back-ordered, the system reroutes that line to a pre-configured alternate supplier automatically, with no chef intervention. The chef sees that it happened; they do not have to do anything about it. If there is no alternate configured, the line stops in a modelled state, the administrator gets an email, and nothing is lost silently.

Every step is appended to an audit trail that a database trigger makes impossible to update or delete: who placed the order, when, which supplier each line was submitted to, the reference the channel returned, and every status change afterwards.

The personas​

Chef / kitchen manager​

The primary user: a head chef or kitchen manager responsible for forecasting ingredient needs and placing the supply order. They work from a browser in the kitchen or the back office. Their goal is one interface where they order everything they need without worrying about which supplier to contact.

A chef is scoped to one or more restaurants and can only see and act on data for those locations. Assignments live in a join table that the API re-reads on every request, so adding or revoking one takes effect on the chef's next click. Their day-to-day journey is documented in the chef guide.

Global administrator​

A single corporate-level operations administrator. They maintain the catalog and the supplier mappings across all locations: which item maps to which primary supplier, which alternate catches its back orders, the supplier-specific product codes, and each supplier's connection details. They also oversee orders and the audit trail across every restaurant.

There is deliberately no per-restaurant admin role. One global admin manages the entire system. Because the admin role also satisfies the chef-level guard, an administrator can additionally do anything a chef can — including placing an order for any active restaurant. Their workflows are in the administrator guide.

Scope​

In scopeOut of scope
Unified catalog, roughly 40 items per supplier in the seedReal-time catalog or ERP synchronisation
Three supplier channels: Sysco (EDI/SFTP), Costco Business Center (email), Central Kitchen (PDF + email)Any fourth supplier
One-action multi-supplier order placementMobile application
Automatic back-order rerouting to a pre-configured alternateChef-driven manual supplier choice
Order history per restaurant, plus an append-only audit trailLive delivery or fulfilment tracking
Inbound Sysco acknowledgments (X12 855) and functional acknowledgments (997)Inbound email monitoring for Costco or Central Kitchen
Two roles, per-restaurant data isolation enforced server-sidePer-restaurant admin roles
Admin catalog, supplier, mapping and restaurant management with no developer involvementInventory system integration
Central Kitchen receiving purchase ordersCentral Kitchen back-office order management

Sysco is the non-negotiable integration. Costco and Central Kitchen are both email-based and lower risk.

Two deliberate departures from the original documents​

Responsive layouts. The PRD lists "no responsive mobile experience" as out of scope. The engineering standards for this build require responsive layouts and browser tests at phone, tablet and desktop viewports, and they won: desktop is the primary target, but every screen — including the cart, which becomes a bottom bar and a dialog — works down to 375px. There is still no native mobile app.

Delivery dates are not modelled. Earlier material said delivery dates are imposed by the supplier and surfaced to the chef. No such field exists: neither an order nor a line item stores a requested or promised delivery date, and nothing in the UI displays one. Chefs never enter a delivery date, which is the half of that statement that did survive. Surfacing supplier-promised dates would need a new column and a place to read it from in the inbound acknowledgment.

What is built today​

The application is complete end to end for the flows described in these pages:

  • the chef screens — dashboard, catalog with cart, review and submit, order history, order detail with live-updating status, dispatches and audit trail;
  • the five admin screens — catalog items, suppliers, SKU mappings, restaurants with chef assignment, and all orders with the global audit feed;
  • order placement with idempotent submission, fan-out to one dispatch per distinct supplier, and the three supplier channels;
  • inbound Sysco 855 and 997 processing on a 15-minute poll, automatic back-order rerouting, and administrator alert emails when a dispatch fails or a back order has no alternate.

Two gaps are worth naming. The purchase-order number the suppliers see is generated and stored but is not returned by any endpoint, so order lists identify orders by a shortened id. And there is no user-directory endpoint: users are mirrored from the identity provider on their first authenticated call, so chef assignment takes a user id rather than offering a list to pick from.

The outcome​

The project succeeds when:

  • a chef can sign in, browse the full catalog, and submit a multi-line order in one action without knowing or selecting a supplier;
  • that one submission produces an EDI file on Sysco's SFTP server, an order email to Costco, and a PDF purchase order email to Central Kitchen — all from the same order event;
  • a back-order notification for any line reroutes that line to its configured alternate and logs the event, with no chef action;
  • a chef can see and place orders for their assigned restaurants only, and cannot even probe whether another location's order exists;
  • the administrator can add a catalog item, map it to a primary and alternate supplier with the supplier's own product codes, and have it appear in the chef ordering interface — with no developer involvement;
  • the administrator can read order history and audit events across every location from one interface.

Where to go next​