A self-initiated product: a booking and ordering system for a billiard club in Tbilisi. I designed it in Figma from scratch and built all of it, from the interface to the database. Guests call the club and nobody answers. They arrive and every table is taken. They want food and wait at the bar. Side Pocket moves all of that to the website. Key decisions No guest accounts. A booking needs a name and a phone number. The guest gets a private link to move, extend or cancel. The link is the account. A 15-minute hold. Guests check in with "I'm at the table." A table nobody claims goes to the waitlist, and the next person gets the same 15 minutes. Ordering tied to the table. Guests order from their phone during the game, add time themselves and see the bill as it grows. One screen for staff. Every table's state for the night, late arrivals and orders to serve pinned to the top, bookings and orders boards, alerts in Telegram. A Telegram bot. It understands "table for 4 tonight at 8" in English or Russian and finishes the booking with buttons. Scope Guest site with live availability, single and group booking, waitlist, private booking page, table page with menu, cart and bill, email confirmations and reminders, staff dashboard, Telegram bot. Stack React 19, TanStack Start, TanStack Router and Query, Tailwind 4, Radix UI, Supabase Postgres with row-level security, pg_cron, Brevo and Resend, Telegram Bot API, Vitest. Business rules sit in plain functions, separate from the UI and the database, with 73 tests. Only server functions touch the database. My role Product design, UI design, front-end, back-end, database, integrations. Live demo: side-pocket.lovable.app

Built for the #LovableChallenge by @Contra and @Lovable. #BuiltWithLovable😊

nicety accomplished.. great work

Building a 4-role real-time SaaS taught me one uncomfortable lesson: the hard part was never the code.

I've been building RestaurantOS — one platform connecting Owner, Kitchen, Waiter, and Cashier in a single live workflow (Table → Order → Kitchen → Serve → Billing → Reports).

The tech stack was the easy part. The real challenge: keeping 4 different roles in sync in real time without any of them stepping on each other's data — a waiter updating a table while the kitchen marks an item ready while the cashier is mid-billing.

That forced decisions most tutorials never cover: ⚡ How much state should live client-side vs. source-of-truth server-side ⚡ What "real-time" actually needs to mean per role (a kitchen screen needs sub-second updates, a report dashboard doesn't) ⚡ Designing failure states — what happens when the waiter's app loses connection mid-order

Currently redesigning the UI/UX layer too (motion, better visual hierarchy) while keeping this real-time core intact.

🔗 nirvaantech.in

If you've built multi-role or real-time systems — curious what broke first for you. And if you're a founder who needs something like this built, my DMs are open.

the role based flow is easy to follow. what part was hardest to keep real time?