The Bid Capital
Bid. Sip. Win.
A full hospitality-tech ecosystem rebuilt end to end — three Android apps, a live TV bid board, and the backend behind them — around one unusual idea: guests don't order drinks, they bid for them.
- Client
- The Bid Capital
- Year
- 2026
- Discipline
- Consumer App · Waiter App · Manager Console · Live TV Board · Backend
- Services
- Product redesign, Android development (×3 apps), React/TypeScript, Backend engineering, DevOps, POS integration
TV bid board · live lots and the hyperbid spotlight
The brief.
The Bid Capital is an upscale café-bar with a genuinely different product: guests don't order drinks at a fixed price — they bid for them.
Bidding runs as a hidden-floor reverse auction, plus timed HyperBid rounds where one lot goes live on the screens above the bar and the whole room competes in real time. The mechanic was loved. The software around it had drifted — five moving parts that no longer felt like one product: a guest app, a waiter app, a manager console, a big-screen bid board, and a Node backend tying them together. A dated light theme, surfaces that had visually diverged, a TV board stuttering on cheap venue hardware and showing stale data, and a backend that had never been hardened against failure.
The mandate: rebuild the entire ecosystem to one bold, gamified, dark identity — without ever touching the bidding mechanic — and ship it to real devices and production, not a prototype.
The objective.
- One identity across five surfaces — a single dark, gamified design system (gold + teal, Barlow, ₹) shared by all four front-ends.
- Rebuild, don't recolor — every screen rebuilt to a rendered design and verified pixel-for-pixel on a real device, not re-tinted from old layouts.
- Protect the core — the bid / HyperBid flow (place bid → “Bingo!” win / “Out of your mind!” lose) stays exactly as it is.
- Make it real and resilient — deploy to production, drive it with honest live data, harden the backend so a restart or reboot is a non-event.
Where it started.
The mechanic was already working. What surrounded it was a light teal-and-orange interface stretched across five surfaces over time, each drifting a little further from the last.
The ecosystem at a glance.
Five surfaces, one service. Three Android clients talk to a single Node backend; the backend drives the TV board over a socket feed and the venue's POS over its own port.
Read as: guest phone, Captain phone and manager console all speak to the Node backend. The backend pushes live lot and purchase activity to the TV bid board over a socket feed, writes to MongoDB, and exposes a separate port for the console and POS.
The guest app — where the night happens.
The consumer Android app is the product in the guest's hand: discover, bid, win, and settle up, all from the table.
The brief
The guest app is the whole product from the customer's side — the only place the auction mechanic is actually experienced.
It had drifted furthest from the brand and was the highest-risk surface to touch, because the bidding flow that people come for lives inside it.
The objective
- Rebuild roughly 15 screens to the dark gamified system.
- Wire the core loop to live data, end to end.
- Keep the bid and HyperBid mechanic untouched.
What we built
A venue gate that unlocks bidding on arrival. A home that surfaces the live HyperBid and tonight's wins. Dark drink and food menus showing bid-from prices against struck retail. The bid screen itself.
Then the rest of the night: the live HyperBid with countdown and current leader, a running tab that shows real savings against retail, order tracking to the table, a leaderboard, rewards with tier progress, and profile.
- Venue gate on arrival
- Live HyperBid on home
- Bid-from vs struck retail
- Countdown and current leader
- Running tab with real savings
- Order tracking to the table
- Leaderboard
- Rewards with tier progress
How it works
The core loop runs on live data — home → menu → tap a drink → bid → win/lose → tab → order. Category chips are derived live from the venue's 329-item menu, and a ~500 m location gate unlocks bidding only once you're actually at TBC.
Tech stack
- Native Android (Java)
- ViewBinding
- Lottie · custom on-brand loader
- Picasso
- Firebase Cloud Messaging
- ~500 m venue location gate
- Live 329-item menu
- Signed release via Gradle
Impact
- A cohesive gamified guest experience, end to end.
- Verified screen-by-screen on a real Samsung device.
- The auction mechanic exactly intact.
Screens · 4
The Captain app — the floor in one hand.
The Captain app — what the waiters carry. It turns a fast-moving bidding floor into a manageable set of tables.
The brief
On a bidding floor, staff need to know not just what was ordered but what was won, and at what price.
The old app couldn't show that, and order alerts silently never fired.
The objective
- Re-skin to the dark system.
- Surface won bids at their won price.
- Make notifications actually work.
What we built
A floor dashboard of every table with live bills and who needs attention first. Order-taking by category that adds to a table's running tab. An itemised bill using the venue's real tax model. A “bid winners” view so staff serve each won drink at the price it won.
Under the hood: live order tracking to the kitchen, shift history, a real notification channel so order alerts actually fire, bill-paid auto-removal, and live table-change sync.
- Floor dashboard with live bills
- Order-taking by category
- Itemised bill, real tax model
- Bid winners at their won price
- Live order tracking to the kitchen
- Shift history
- Bill-paid auto-removal
- Live table-change sync
How it works
Three push channels — order, bill-paid, table-change — plus a corrected tax model: VAT 10% on drinks, GST 5% on food.
Tech stack
- Native Android (Java)
- FCM · order / bill-paid / table-change
- VAT 10% drinks
- GST 5% food
- Waiter + POS endpoints
- Signed release
Impact
- Waiters see the whole floor, the won bids and the bills at a glance.
- Real-time nudges instead of manual refreshing.
Screens · 4
The manager console — the control room.
The manager's cockpit for the whole venue — the one place the operation is configured and watched.
The brief
Every menu change used to need a developer.
The console had to become the single place a manager runs the venue, without anyone shipping code.
The objective
- Rebuild in phases to the dark system.
- Give managers true self-serve over menu, floor, staff and hype rounds.
- Enforce it server-side so changes land instantly.
What we built
A control dashboard with tonight's sales and live lots. Full drink and food menus with per-item availability toggles and prices. A new Category Manager to show, hide and time-schedule categories.
Then the operation around it: tables with capacity, status and waiter assignment; staff management; scheduled HyperBid rounds that light up the board; bookings and reception; and a live report with revenue, top drinks, and the night by the hour.
- Tonight's sales & live lots
- Per-item availability toggles
- Category Manager · show / hide / schedule
- Tables, capacity & waiter assignment
- Staff management
- Scheduled HyperBid rounds
- Bookings & reception
- Live report by the hour
How it works
The Category Manager persists through new backend fields and is enforced in the consumer menu endpoint — so “Eggs all day, until 7 PM” lands on every guest phone instantly, with no deploy.
Tech stack
- Native Android (Java)
- Fragment / adapter architecture
- Firebase
- Server-enforced category schedule
- New backend fields · existing data untouched
- Signed release
Impact
- Managers run the menu, floor, staff and hype rounds themselves.
- No developer in the loop.
Screens · 4
The TV bid board — the room's heartbeat.
The big screen above the bar turns private bidding into a shared, competitive spectacle — the thing that makes the room lean in.
The brief
The board is the venue's theatre.
It was stuttering on cheap venue TVs and showing stale activity, which quietly undermined trust in the whole mechanic.
The objective
- Rebuild from scratch against the live socket feed.
- Show only fresh, honest data.
- Run smoothly on weak hardware.
What we built
A 3×3 grid of live lots with per-tick price movement. A “just bought” overlay celebrating real purchases, with a “steal” flag on big savings. A HyperBid spotlight with countdown, and a live “N bidding now” pulse.
It ranks lots by genuine recent activity and enforces up-only pricing, so nothing on the wall contradicts what's happening on the floor.
How it works
It listens on the live socket contract — drinks / feed / pricechanged / feedadded / hyperbid. We root-caused several backend feed-ordering bugs that had been surfacing stale activity. A dedicated “lite” performance mode freezes ambient animation and drops gradient-clipped text that stalled older browsers, so it stays smooth on cheap venue TVs.
Tech stack
- Vite + React + TypeScript
- socket.io-client v2 · matching the server
- Live socket contract
- “Lite” performance mode
- systemd service
- Threaded static server
Impact
- A board that's live and smooth on weak hardware.
- Truthful on the wall — real buys, real bid counts, real timestamps.
Screens · 2
The backend — the spine.
A single Node service ties every surface together — the apps, the board, and the POS.
The brief
The backend had never been hardened against failure.
A roughly 13-hour outage made that concrete. It is the inflection point of this chapter, and the reason the rest of it exists.
The objective
- Enforce the new category rules server-side without endangering existing data.
- Fix the stale-feed root cause.
- Make a restart or reboot a non-event.
What we built
Server-side enforcement of category hide and schedule in the consumer menu endpoint, using new fields so existing data stayed safe. A daily leaderboard and a nightly price reset.
And root-cause fixes to feed ordering that had been surfacing stale activity across every surface — the board, the apps, the console.
How it works
After the outage we migrated the runtime from forever to PM2 and hardened the box — disk, swap, boot resurrection, and a watchdog — closing a latent Node-version landmine that would have crash-looped any restart or reboot.
Tech stack
- Node.js / Express
- MongoDB
- PM2
- CronJobs
- Firebase Cloud Messaging
- AWS EC2 · ap-south-1
- Watchdog + boot resurrection
- Separate socket / user / console+POS ports
Impact
- A backend that survives restarts and reboots.
- Honest data on every surface.
- Menu changes without a deploy.
Read as: one EC2 box runs the Node service under PM2. Three ports separate the socket feed to the board, the user API for the two phone apps, and the console + POS API. MongoDB stores the venue; cron jobs run the daily leaderboard and the nightly price reset; FCM carries push. The watchdog and boot resurrection are what turn a restart into a non-event.
Tech stack.
Guest app
- Native Android (Java)
- ViewBinding
- Lottie
- Picasso
- FCM
- ~500 m venue gate
Captain app
- Native Android (Java)
- FCM order channel
- Bill-paid channel
- Table-change channel
- Waiter + POS endpoints
Console app
- Native Android (Java)
- Fragment / adapter architecture
- Firebase
- Signed release
TV board
- Vite + React + TypeScript
- socket.io-client v2
- “Lite” performance mode
- systemd service
- Threaded static server
Backend & infra
- Node.js / Express
- MongoDB
- PM2
- CronJobs
- AWS EC2 · ap-south-1
- Watchdog + boot resurrection
Money, data & delivery
- VAT 10% drinks / GST 5% food
- 329-item live menu
- Server-enforced category schedule
- Daily leaderboard & nightly price reset
- POS billing-provider migration
The impact.
For the business
- One modern brand across every surface — guest app, waiter app, manager console and the screens above the bar finally look like one product.
- A live TV board that holds up — smooth on cheap venue hardware, real purchases and real bid activity instead of stale data.
- A backend that survives itself — migrated to PM2 and hardened with a watchdog, so a restart or reboot no longer means an outage.
- Managers self-serve the operation — menu, categories, tables, staff and scheduled HyperBid rounds, without a developer.
- A de-risked POS migration — the billing-provider switch was scoped and pressure-tested before a line of integration code was written.
For the guest
- A cohesive, dark, gamified night — end to end, on the phone and on the walls.
- The bidding kept intact — the reason people come, preserved and running live.
- Honest, real-time data — real wins, real bid counts, honest timestamps.
- Faster service — waiters see the whole floor, won bids and bills at a glance.
What changed, surface by surface
- Guest app
- The whole night, dark and gamified, with the bidding mechanic untouched.
- Captain app
- Won bids at their won price, and order alerts that actually fire.
- Manager console
- Menu, floor, staff and hype rounds — self-serve, no deploy.
- TV bid board
- Rebuilt on the live socket feed: smooth on weak TVs, honest on screen.
- Backend
- PM2, a watchdog and boot resurrection — a reboot is now a non-event.
