Why our palette is vibrant blue (and not terracotta red)

By August it was time to stop theorizing and start picking colors. A design system is one of those things that seems minor until you touch it: get it wrong and you drag it for years. So we sat down with a couple of designers and spent nearly three weeks on something the original plan had down as "an afternoon".

The question we got asked most by friends in the industry was: why a vibrant blue instead of the terracotta red or olive green you always see in hospitality? Let's break it down.

The hospitality color cliché

If you look at restaurant tools, still-life menu photos, wedding-menu templates… the same four colors dominate: terracotta red, chocolate brown, olive green, and cream. They are colors that evoke food, taverns, warmth. Fine.

The problem is we are software, not food. And restaurant owners spend eight hours a day staring at screens with those saturated warm tones. The result: visual fatigue and the feeling that the tool is trying to hide that it is a tool.

We wanted to flip that: make the interface feel closer to a polished productivity app than to a printed menu.

The palette

Concrete decisions we made:

• Primary blue in oklch. Vibrant, with strong contrast on both white and dark backgrounds. We work in the oklch color space because it lets us shift lightness without the hue "jumping".
• Cool-leaning neutrals. Slightly bluish grays, not browns. Adds a sense of order.
• Warm accents only for alerts. Orange for warnings, red for errors, green for confirmations. Nothing else. If everything is important, nothing is.

The typography

We picked Geist Variable. Three reasons:

• It is a variable font, so it weighs less in production than loading four separate weights.
• It has a modern geometric feel without the clinical edge of Helvetica or the "techy" vibe of Inter.
• Its tabular numerals make reservation and price tables line up without effort.

Density and whitespace

We argued plenty here. The temptation, in a management tool, is to cram a lot of information per screen. The rule we ended up with: two clean screens beat one cluttered screen. Components have generous default padding, and only get compressed in live service views, where you really do need to see many reservations at once.

What we left for later

Dark mode went on the "not yet" list, even though we knew we wanted it. It stayed as a CSS-variable layer, ready to switch on once the rest of the product was stable. Spoiler: it eventually shipped, but not without scratching out a couple of ugly bugs.