Inspiration
A shared menu does not mean every branch can serve every dish.
The idea for Second Serving grew from observing food-chain stores in Japan, where local equipment, ingredients, and operating conditions can limit what a branch actually offers.
Instead of building another recipe generator, I wanted to connect branch capabilities with a practical question: when one kitchen cannot fulfil an order, can another branch help—and under what conditions?
What it does
Second Serving is an AI-assisted operations workspace for fast-food and takeaway chains.
It connects shared menus and recipes with branch-owned inventory, equipment, operating capacity, and incident reports. Managers can see which dishes are currently available and understand what is blocking others.
When service is interrupted, managers can request prepared-food support from another branch. The application checks stock, equipment, capacity, queue time, approved delivery routes, dish travel limits, and customer deadlines.
Transfers follow an explicit workflow:
Request → Approve and reserve → Prepare and consume stock → Dispatch → Receive.
These are prepared-food transfers, not transfers of raw ingredients. Equipment repair and incident resolution remain separate responsibilities.
How I built it
The application uses a Node.js backend, an HTML/CSS/JavaScript frontend, and PostgreSQL for persistent operational data.
NVIDIA Nemotron provides incident advice through runtime calls to Nebius Token Factory. The model receives the selected incident and operational context, then suggests next steps for manager review.
AI advice is deliberately separated from execution. Deterministic application rules validate feasibility, and managers confirm operational changes. The model cannot approve transfers, alter inventory, or mark equipment as repaired.
PostgreSQL transactions protect related inventory and transfer changes. Approval reserves ingredients; starting preparation consumes them at the source branch.
Challenges I ran into
One major challenge was separating shared definitions from local ownership. A chain-wide ingredient catalog should not imply shared stock, and an equipment name should never determine which branch owns it.
Another challenge was maintaining correct inventory across requests, reservations, preparation, cancellation, and competing operations.
Usability also required several iterations. Reviewing actual interaction recordings helped improve branch context, setup guidance, recovery steps, and error messages.
Accomplishments that I'm proud of
The recorded demo shows a complete simulated recovery: a rice-cooker failure affects nine veggie rice bowls at Akasaka Pickup. After a manager approves a delivery route, Shinjuku East becomes an eligible source with an estimated total time of 18 minutes.
The transfer then progresses through approval, preparation, dispatch, and receipt, with explicit human confirmation.
The project also includes 57 application tests and 15 PostgreSQL checks covering permissions, persistence, inventory reservations, rollback, demo-data safety, and transfer workflows.
What I learned
Operational AI is most useful when its suggestions are grounded in explicit constraints and paired with clear human responsibility.
I also learned that a technically valid workflow is not automatically an understandable one. Ownership labels, guided setup, and visible explanations matter as much as the underlying calculations.
What's next for Second Serving
The next step is to validate the workflow with real chain managers, improve production deployment and authentication, and explore POS integration to reduce manual stock updates.
The current prototype uses fictional demonstration data and manually configured planning assumptions. It does not provide live courier tracking, food-safety certification, or measured business-impact claims.
Built With
- nextjs
- react
Log in or sign up for Devpost to join the conversation.