Diana Kitchen

The problem

A food vendor takes orders on WhatsApp all day: what's left, what it costs, who has paid, where it goes. Every answer lives in her head or in a thread, and the moment she is at the pot, ordering stops.

The approach

A menu customers order from with no account, no password and no app to download, and a vendor side she runs from her phone between cooking. The server owns every rule about stock, money and order state — neither the customer site nor her screens are allowed to decide any of it.

The build

• —Ordering with no sign-up — plates are reserved when added to the cart and released on a timer, so two customers can't buy the last one
• —Payment by bank transfer to a virtual account per order, with every credit verified server-side rather than trusted from the webhook
• —Multi-day menus that roll over at midnight, so today and a published tomorrow are live at once and an order belongs to exactly one day
• —WhatsApp confirmations and a vendor inbox with threaded replies, queued and retried outside the payment path
• —An append-only wallet ledger with on-demand withdrawals behind a row lock and an idempotency key
• —A vendor dashboard for the day's orders, the menu, delivery areas, riders and customers — rebuilt around one row per dish after the first version needed 42 forms
• —Nightly database backups read back with pg_restore before they count

The outcome

Live at dianakitchen.ilesa.tech, cooking for a real vendor in Ilesa. Laravel API and vendor dashboard deployed by Coolify, customer site on Vercel.