What the catalog had to forget about restaurants
Build the abstraction when the second customer asks. Not the first.
~1 min · 243 words
The UI said “dish” and “menu” everywhere — because the first pilot was Lumière, a restaurant, and the product was shaped by the business we worked with day to day.
Then we onboarded the first clinic. A dermatology studio doesn't have a “dish.” It has a treatment. A hotel doesn't have a “menu.” It has a room list. The catalog still worked technically — the database doesn't care what we call a row — but the words in the interface lied to the owner. The dental practice opened the app and saw “Add a dish.” Nobody types that and feels at home.
We pulled the restaurant vocabulary out and made it configurable. Each business sets its own section name and item noun at setup. The dental clinic types “treatment.” The hotel types “room.” The restaurant still types “dish.” The product stops pretending to be a restaurant tool while staying native to a restaurant.
This is a small change that taught us a big rule. Build the abstraction at the moment the second customer asks for the wrong vocabulary, not the first. The first customer's words are not the product's words. The product's words emerge when the second customer's words refuse to match the first's.
“The first customer's words are not the product's words.”
We caught it at customer two. If we'd hardcoded another month, the cost of pulling “dish” out would have been doubled by every screen that learned to say it.