Restaurant POS, Built In A Browser
I joined Divine as the founding designer. The goal was to take on the big point-of-sale companies that take a percentage of every sale and lock restaurants into proprietary hardware. I designed a product that runs in a browser tab on whatever device the operator already owns.
The big point-of-sale companies take a percentage of every sale and lock restaurants into their hardware. Divine wanted to do the opposite. My job was to make a software-only product feel as serious and finished as a full hardware setup, which is the part nobody else in the category was getting right.
I designed the product for the people actually using it. The cashier ringing in a takeout order during the Friday rush, the owner editing a menu at 11pm, the customer ordering from their phone. Each of them got their own surface in the product. Then I designed the brand and the marketing site so the whole thing felt like one company.
A point-of-sale that runs in a browser on any device the operator already owns. No app to install, no proprietary terminal. The features competitors normally charge extra for, like ingredient inventory and an online ordering page, are bundled in.
The person using this screen is not relaxed. They are taking an order while the phone is ringing and someone is asking about gluten free crusts. Every decision on the page comes from that. Tiles are big enough to tap without looking. Photos are real photos because recognizing pizza is faster than reading "Pepperoni Pizza." Categories sit as a single row of tabs at the top so the cashier never scrolls to find a section. The current order pins to the right at full height, because the worst thing you can do during a rush is hide what just got added.
The one design decision I would point at first if someone asked me what I am proud of in this project lives on this screen. Editing a menu item in most restaurant point-of-sale systems is a form you fill out, save, then check on another tab. If it looks wrong, you go back and repeat. I watched an owner do this with a competitor and counted nine tab switches to add one pizza.
So I split this screen in half. The settings live on the left. The right side shows the menu card the way the customer will see it on the online store, updating as the owner types. This is normal for design tools like Figma but rare in back office software. Watching a small restaurant owner light up the first time they used it was the moment I knew the project was worth a couple of years of my time.
The first version of the menu editor had toppings configured on each product. Pizza one had its own list, pizza two had its own list, and so on. Then I watched an owner try to add sundried tomatoes to their menu and realized they had to open every pizza and add the new topping one at a time. For a 20-pizza menu, that is 20 edits to add one ingredient.
I redesigned it around the idea of a template. The pizza toppings list is one thing that lives on its own page, and it is linked to every pizza on the menu. Add sundried tomatoes to the template once, every pizza picks it up. The owner can see the structure of the whole menu on one page, and each template card shows how many choices it has and how many products are using it.
I had to fight the temptation to put twenty charts on this screen. The four numbers across the top tell the owner whether yesterday was good and whether they need to call someone in to cover dinner. The pickup, delivery, and in-store breakdown below them decides whether the kitchen or the front of house is the bottleneck. The order wait time row at the bottom catches a shift running slow before the customer complains.
I chose a table here because the owner usually comes in to make a small change to one item and needs to scan the whole menu to find it. Cards or a grid would slow that scan down. Each row shows the photo, name, description, price, category, attached options, status, and quick actions. Price edits happen inline instead of in a modal, because changing a price is the most common edit and modals are slow.
Most point-of-sale products that even have inventory track it at the menu item level. They will tell you how many pizzas you have left, which is useless because a pizza is not a thing you keep in stock, it is a combination of cheese and dough and sauce and toppings. I designed this around the ingredients themselves. The kitchen manager sees mozzarella in kilograms, pizza dough by count, each with a low-stock alert before they run out. Most competitors sell this as a separate $50/month add-on. I included it because it uses the same data the rest of the system already has.
Most online ordering services charge a restaurant either a flat monthly fee or a percentage on every order. For a small restaurant doing ten online orders a day, that adds up fast. I debated bundling this in for free, since we were already running the menu data and the customer storefront is just a different view of it. The settings screen is intentionally small. The owner picks a URL ending, drops in their own payment keys, picks a logo and a background colour, and turns it on. Orders route back to the same point-of-sale the staff already uses.
The hardest customer-side problem to design was the combo. A pizzeria's combo deal is often something like "two three-topping pizzas plus two dipping sauces." A flat checkbox list of toppings does not work here, because the customer wants different toppings on each pizza. Most online ordering systems I looked at either flattened this into one big list and let the customer pick six toppings total, or they made it a confusing nested form. I designed it as a wizard. Step one is the size for both pizzas. Step two is the toppings for pizza one. Step three is the toppings for pizza two. Step four is the extras. The customer never has to do the math in their head. The running price stays pinned to the left and updates as they pick.
Most of the design work after month one was downstream of three early decisions. If any one had gone the other way the product would be a completely different thing.
This was the most debated decision early on. A native iPad app is the convention in restaurant point-of-sale. I pushed for a browser-based product because a small operator might be running the floor on a four-year-old iPad and the back office on a Windows laptop. Asking them to install three different apps is a tax. A browser tab works on all of those devices, updates ship instantly, and training is faster because everyone already knows how to use a website.
The competitors all bundle payments and take a cut of every sale. I debated the opposite and the team went with it. The operator keeps whatever payment processor they already have, the product never sees the money, and the settings screen is just a place to paste in their own keys. The legal complexity of handling card data also disappears for us, which makes design simpler in a lot of places I would not have predicted.
Online ordering, ingredient inventory, kitchen display routing, staff scheduling, all of these are usually upsells on the products we are competing with. I bundled them because the underlying data is the same. A point-of-sale already knows what items are on the menu, what got ordered, who made the order, when. Once you have all of that, building an inventory view or a kitchen display is a different view of data the product already has, not a new product. Pricing flat instead of per-feature also made the design of the settings simpler, because there is no upgrade gate to design around.
I also designed the marketing site. The thing I debated hardest was the hero. Every competitor opens with a stock photo of a smiling barista. I went the other way and put the actual point-of-sale chrome in the hero, the same thing the operator will see when they log in. The buyer is evaluating software, not a feeling about coffee.
I avoided the obvious food-tech brand language. No warm amber, no chalkboard fonts, no implied story about a smiling family-owned cafe. The brand is for the person who runs the place, not the person who eats there. I went with a slate palette and a deep navy for product chrome because that reads as a serious tool. The marketing typography is Plus Jakarta Sans because it feels modern and confident without trying to be cute. The voice is direct and avoids the SaaS vocabulary I noticed competitors using a lot, like "leverage" and "innovative" and "solution."
One family across the whole product and marketing site. Big confident weight for headlines. Reads as a tool for running a business, not a love letter to food.
A slate palette for the marketing site, deep navy for the product chrome. No accent colour. Red and emerald only show up when they mean something functional like an error or a success.
Two-line headlines with a bold claim and a softer follow-up. "Your POS. Your Rules. That's Divine." I kept a list of words I would not use, including "innovative," "leverage," "solution," and "empower."
Most restaurants pay for a point-of-sale, an online ordering service, an inventory app, and a payments processor that takes a cut on top. I designed Divine to do the first three under one subscription and stay out of the way on payments.