A handheld POS that fits in a server’s pocket.

It started with reliability. A countertop POS went down for a full day, and about $600K in payments couldn’t go through. The company’s priority became clear: get a handheld live, fast, so no restaurant ever depends on a single terminal again.

But the handheld also had to fix a problem that happened every day, not once. A server writes the order on paper at the table, walks to the counter to enter it, walks back to confirm. At peak hour those trips pile up: they slow the kitchen, limit table turnover, and cause mistakes. Mobile POS exists to fix both — bring ordering and checkout to the table, and keep running when the counter can’t.

Mobile POS is built for trained restaurant servers working under real pressure: standing, in a loud room, guests watching, device in one hand.

Their job at one table runs in a fixed order: seat, order, modifiers, coursing, send to the kitchen, serve, split and pay, close. Before Mobile POS, every one of those steps had to be keyed into the counter POS. Five of them — entering the order, its modifiers and coursing, sending it to the kitchen, and taking payment — come up while the guest is still waiting, so they pulled the server away from the table mid-service. That’s where the trips came from.

Because these are trained users, the design goal is not “understandable at first glance.” It’s operable by muscle memory, and error-free at peak hour. That allows higher information density than a consumer app, and demands far stricter consistency in return: the controls and primary actions stay in the same place, on every screen.

The brief was “make it mobile.” The real question was which of the seventeen desktop functions belonged in a two-month MVP. Two kinds of research answered it.

• Field observation — I watched servers work in real restaurants. The complaint that came up most was some version of “I’m away from my table.” I also watched how they hold the device: left hand holds, right thumb taps, standing the whole shift
• Feature audit — I went through the desktop POS’s complete feature list, one function at a time, and mapped where each one actually happens: at the table, or at the counter

Put together, the answer was clear. Servers didn’t need a smaller POS. They needed fewer trips.

Ordering, checkout, order history, and member cards moved onto the phone, one tap away. Reservations, waitlist, staff management, and inventory stayed on the countertop POS, deliberately.

Some features were split down the middle. Table management is the clearest case: editing the floor plan is a manager’s task, done once, so it stayed on the desktop. Reading the floor — who sat down when, who’s running long, which table is empty — is a server’s task, every few minutes. That moved to the phone as a bird’s-eye view, color-coded by status.

The cost is a less complete first version. But Mobile POS was never meant to replace the terminal. It exists to perfect the part worth carrying — and the scope was agreed with the PM and engineering before a single screen was drawn.

You can’t shrink a desktop onto a phone: the targets get too small, and servers use it one-handed. So before any screen, I wrote the principles. Each one answers something seen in the field.

With the rules set, migrating dozens of screens stopped being a debate. Each one became “apply the principle.”

Mobile POS has a moment a countertop terminal never faces: at checkout, the device turns to face the guest. In one second the user changes — from a trained employee to someone who has never seen this screen, choosing a tip and signing while the server stands right there.

So the staff-facing side is optimized for density and speed, while the guest-facing tip and payment screens are deliberately minimal, with unmistakable amounts. If the guest hesitates, it’s awkward for everyone — those screens went through more review rounds than any other.

Office software assumes you finish what you start. A restaurant floor never lets you: mid-order, another table waves, the kitchen calls, a guest changes their mind. Every core flow therefore had to be safely interruptible and resumable — an unsent order holds everything entered, and the server picks up exactly where they left off instead of starting over.

The whole app is black, white, and gray. In a busy restaurant, color has to mean something, so it appears in exactly two places:

• Table status — open, dining, and running-over tables each carry one status color. A server reads the entire floor in a glance, without reading table by table
• Dish categories — in a grid hundreds of items deep, each category has its own color. Finding a dish turns from reading into scanning: lock the color zone first, confirm the name second

One more rule sits underneath: anything tappable is a solid block; plain text is information only. The number pad’s outlined keys became solid blocks for exactly this reason. Servers never have to guess what’s a button.

Everywhere else in the system, I removed steps. Two actions got one added. Voids and discounts cost the restaurant money, and a void can’t be undone — so both require a manager PIN.

It’s the one place that deliberately breaks the shortest-path rule. Fast everywhere, except where a mistake costs money.

The one real disagreement on the project was the foundation. I proposed Material Design 3: a shorter learning curve for servers, and faster design work. Engineering pushed back — restaurant tech is a deep vertical with custom workflows, and generic components wouldn’t fit.

Instead of debating, we ran a one-day A/B test with real servers, comparing task completion, speed, and confidence. Servers learned Material 3 faster. Engineering was right too: some restaurant patterns simply don’t exist in Material. So we kept Material’s structure and tokens, and built our own components only where restaurants needed them.

That became a componentized design system:

• Component variants for buttons, inputs, modals, and list items — covering size, state, and use case
• Semantic color tokens, so Light and Dark Mode share one component structure — no parallel design files to maintain
• Interaction rules baked in — every new screen inherits the principles automatically

Screen design turned from “drawing page by page” into “assembling from components,” and design and engineering gained a single source of truth.