Biller — a cloud POS a waiter, a cook and an owner can share

01Context

Independent restaurants in India mostly run on paper pads, WhatsApp messages to the kitchen, and memory. Enterprise POS systems exist, but they are priced, sold, and — crucially — designed for chains with trained staff and an IT contact. Biller is a cloud POS built for the single-outlet restaurant: AI menu scanning, a shared billing board, a kitchen display system, QR guest ordering, WhatsApp bill delivery, inventory, menu and customer management, and analytics — on a credit-pack pricing model with a genuinely free tier (100 bills a day costs nothing).

This is a real, live product — it shipped at biller.app in June 2026. It's also a long-held idea: a first, local-only version was built back in late 2019 but never shipped. We picked it up again in January 2026 and rebuilt it for real. It's personal, too: I designed it, and my husband, the primary developer, built it. Two people, no funding, real users to win.

02The hardest problem: one home, four roles

A POS in a small restaurant isn't used by "a user." In the space of one lunch rush, the same screens are touched by a waiter taking orders, a cook working through tickets, a cashier settling bills, and an owner who wants to know how the day is going. Big vendors solve this with separate apps and training. A two-person team can't ship four apps — and a six-table restaurant won't sit through training for even one.

The answer Biller shipped with is a single billing board: one list of live bills, where each bill carries its workflow state (Pending → Kitchen → Preparing → Ready) as a colored, labeled status instead of living in a different app per role. Waiters create and add; the kitchen flips states from the ticket wall; the cashier settles from the same card; the admin's tools sit one tap away in the sidebar. Same mental model for everyone: a bill is a card that moves through states. The second design fight was scope: inventory, customer management and analytics are enterprise features, and enterprise UIs came with them. Each one got re-asked as an SMB question — "what would the owner of a six-table restaurant actually check?" — and cut down to that: inventory leads with low-stock highlights, not stock ledgers; insights lead with plain sentences ("Sales are up 13.7% this week, led by Paneer Tikka"), not chart grids.

03The key decision: mobile-first, AI-first onboarding

Before any pixels, I talked to real restaurant owners around us in Bangalore about why they didn't already use a POS. The blocker was never billing — everyone can press buttons on a billing screen. The blocker was setup: getting a full menu, with prices, variants and categories, into the system. That's an afternoon of data entry, so it becomes "next week," and next week never comes. Onboarding friction, not feature count, was the real competitor.

So the product's core became an AI menu scanner: take photos of the physical menu card — the one every restaurant already has — and let AI build the catalog: items, prices, categories. A printed menu becomes a working POS in under two minutes, and the whole restaurant is onboarded in a few clicks. Everything else in setup follows the same principle: the system does the tedious part, the owner only confirms. And because the counter is a phone, not a terminal, every screen was designed mobile-first and then widened to tablets and laptops — not the other way around.

04Process: scrappy on purpose

This project ran nothing like an agency engagement, and I won't dress it up as one. The loop was: rough notes from owner conversations → flows sketched in a notebook → wireframes generated with AI assistance → straight into the build. My developer works AI-first, so instead of polishing Figma mockups he'd never open, I specified structure, states and copy, generated wireframes with AI tools, and we argued over the result on a phone screen — usually the same day. Design reviews happened in the running product.

• What I owned: the problem framing, owner interviews, role model, information architecture, screen structure, interaction states, naming and copy — and saying no to enterprise clutter.
• What I gave up: pixel-perfect design files. In a two-person team racing to launch, a maintained Figma library was overhead the product didn't need yet.
• What that taught me: the artifacts are negotiable; the thinking isn't. Working lean sharpened exactly the skills I use in enterprise settings — deciding what matters and proving it in the shipped thing.

05The product, in five screens

All screenshots below are the real, live product at biller.app.

06Where it stands

Biller launched in June 2026 — weeks ago as I write this. There are no adoption numbers to report yet, and I'm not going to invent any. What exists today: a live, working product at biller.app, with a free tier a real restaurant can run on, now in the hands-on phase of winning its first signups in Bangalore.

What I'll measure next, in order: whether scanned-menu onboarding actually completes without help (activation rate and time-to-first-bill); whether the shared billing board survives a real lunch rush across roles (task success and abandoned bills); and where the free-to-paid boundary lands against the credit-pack pricing. Those answers — not launch — will tell us if the design bets were right.

07What I took from it

CAPEI taught me to design inside constraints someone else set. Biller taught me to choose the constraints myself: what to cut, what the one core bet is (onboarding, not features), and how to keep enterprise-grade capability behind an interface a first-day waiter can use. It's the first product where I owned the "what" as much as the "how" — and the first one where the design review is the market.