We shipped the half a restaurant could use tomorrow.
We'd built a full restaurant POS that would burn cash before it earned any. So we shipped the lighter half first: a QR menu a restaurant could put on the table the next day. That brought revenue sooner, and a warm lead for the POS later.
Ship the near half first
We had already built a full restaurant POS. It would burn a lot of cash before it earned any. So instead of waiting on it, we shipped the lighter half: a QR menu a restaurant could put on the table the next day. The point was to earn sooner, and to turn every restaurant that took the menu into a warm lead for the POS. I'm a co-founder here, not a hired designer, so this was a business call as much as a design one.
Cheap to run, live the next day. Earns while the POS is still expensive, and puts us in front of the exact restaurants it's built for.
Already built, but heavy to sell cold. The menu was meant to open the door to it, one warm lead at a time.
Guests read. They don't order.
The menu is browse-only. No cart, no checkout, no payment. That isn't a feature we ran out of time for. It's a line I drew. Ordering and payment are the POS's job. But a guest still wants to keep track, so there's no cart, there's a list. A guest marks what they like, sees what it adds up to, then says it out loud to the waiter, the way they always have. The screen says so plainly: this is not an ordering system.
The menu they already have
Every restaurant has a menu. It's a PDF, or a photo of a printed card, and getting it into a new system is the first wall most owners never climb. So the product reads it. Upload the file, and the AI pulls the categories and the dishes out of it: forty-four products, seven categories, from one PDF. Then the owner reviews every item before a single one is imported. The machine drafts. The person decides.
The AI images are my old job
I trained as a food photographer. For eleven months I shot restaurant dishes and designed printed menus. The restaurants that paid for good photos got more business. I watched it happen. But most owners couldn't afford the per-shot fee, or a designer for the menu.
A tripod, a reflector, one dish, a laptop off to the side.
This is what a good photo actually cost: my time, my gear, a trained eye, one plate at a time. It worked, and it was worth it. But at that price, most owners never got it. They shot the plate on their phone, or they showed nothing at all.
The AI generation isn't a feature I added because the tech existed. It's the exact thing I used to charge for, made cheap enough that any owner can have it. It doesn't invent a dish. It takes the plate they already cooked, shot badly on a steel counter under kitchen light, and gives it the light I used to spend an afternoon setting up.
the owner's phone photo · the same plate, processed
No single template
A kebab house and a third-wave coffee bar shouldn't wear the same menu. A menu is part of the room. That's why there's no fixed template: I designed several styles and built them into the product, and a restaurant picks the one that fits.
Two ways in
We built a full dashboard first: menus, promotions, images, all of it in panels and forms. Then I watched owners use it. Most weren't comfortable with software. But every one of them was already fluent in one interface: AI chat. So we built the whole thing again as a conversation. An owner sets a weekend discount, changes a price, or replaces a dish photo by asking for it, in German, English or Turkish. Neither interface is the real one. The dashboard is there for owners who want to see everything at once. The chat is there for the ones who'd rather just say what they want.
Two things make the chat trustworthy. It never acts before it's confirmed: it proposes, the owner approves, then it writes. And everything it does lands in a history. Price changed 6,50 to 7,20. Promotion started. Photo uploaded. A conversation you can audit is a conversation you can rely on.
It proposes. The owner confirms. The history remembers.
THE OTHER DOOR // the dashboard, for owners who'd rather see everything at once
How I worked
I made the design decisions: the hierarchy, the flow, what the product would and wouldn't do. Claude Design and Claude Code let me move from an idea to a working screen quickly. The tools sped up the execution. They didn't make the calls. Four months, from start to shipped. Solid, not miraculous.
The reasoning is what I'd defend.
We're not running it right now. Startups stall for reasons that have little to do with whether the work was good, and this one stalled. I can't show you a revenue chart. What I can show is the call itself: ship the part guests could use tomorrow, and design it as the door to everything after. That's the part I'd stand behind.