Lot 01 — VIBECODE · SHIPPEDof 03

Anumaan

Agentic restaurant operations for independent Indian restaurants — built solo in three days.

Plate I — hero image1440 × 630

Role

Solo — PM, spec and build

Timeline

July 2026 · 3 days

Instruments

Claude CodeNext.jsSupabaseGroqVercel

Live

anumaan-vibeathon.vercel.app ↗

I. Overview

An independent Indian restaurant runs on a WhatsApp group, a paper KOT pad and the owner's memory. Anumaan puts one source of truth across three surfaces — a scan-to-order customer PWA, a kitchen display and an owner's dashboard — and adds an agent layer that drafts a decision, shows its basis, waits for approval, and logs what it did. Built for VibeAthon 6.0, specified as a PRD and FRD first and then vibecoded end to end with Claude Code.

II. Condition Report

The incumbents in this segment digitise the recording of restaurant operations. None of them ship an agent that notices a problem and proposes a fix — the owner still learns paneer ran out when a diner sends back a dish, and still forecasts demand by feel. That gap was the whole product. The hard part was not generating the software; it was deciding what an agent is allowed to do in someone's business, and proving it holds.

III. Restoration Approach

1.Wrote the PRD and FRD before any code, so every feature had an FR id the build could be graded against rather than a vibe.

2.Kept the forecast as arithmetic, not a language model — weekday average × a clamped trend factor, unit-tested — and gave the LLM only the job of narrating the number, with its basis printed beside it.

3.Grounded the briefing and the Ask surface in one assembled data object and nothing else, so an item that never sold is simply absent from the model's context and it has nothing to invent from.

4.Moved guardrails out of the system prompt and into code after measuring the failure: told it could not contact suppliers, the agent agreed in words and proposed a restock anyway, 3 trials out of 3. A prompt is a strong prior, not a guarantee.

5.Put the approval gate in the route handler rather than the UI, so a forged or replayed request still cannot execute anything a human did not approve.

6.Made the eval suite a JSON file the runner reads directly, with human-graded cases printing as MANUAL rather than as passing.

Plate II — flow diagram

Plate III — before / after

IV. Appraisal

14/17

eval cases passing — 3 human-graded by design

192

unit tests, plus 143 smoke assertions on the live URL

3 days

solo, from problem statement to deployed product

V. Specialist's Note — What I'd do next

The lesson I took into every build after this one: decide what must be true, then enforce it in the layer that cannot be talked out of it. Next I'd cut the surface area — six agents is two more than a first-time owner can hold in their head — and earn the seventh only once someone has actually run a week of service on it.

Next lot

GPT-Live

→