What a coffee shop taught me about building software

When I started building the system for Wendo, I thought I understood restaurants.

I'd eaten in a hundred of them. I had the whole thing mapped in my head — orders go from the table to the kitchen, stock goes down as food goes out, the numbers add up at the end of the night. Clean. Obvious.

So I designed it. Clean and obvious. Then I spent a week standing in an actual restaurant, watching it run.

Almost none of my assumptions survived the week.

Here's one. In my head, an “order” was one thing — you order it, someone makes it, it comes out. But on the floor, a single table is three orders wearing a trench coat. The food goes to the kitchen. The drinks go to the barista station on the other side of the room. And those two stations do not care about each other even a little.

That wasn't even the big miss. The big miss was what was actually slowing them down. I assumed it was writing the order. It wasn't. It was the not-knowing.

A waiter takes an order, walks it to the kitchen, and then has no idea. Is it being made? Is it done? Did anyone start it? So they walk back. And check. And walk back again. Twenty times a night. The whole place ran on people crossing the room to ask “is it ready yet.”

You cannot see that from a chair. You can only see it standing in the corner for six hours, getting in everyone's way.

So I threw out the clean design and built the messy one — the one shaped like the actual room. Orders that split themselves, food one way and drinks the other. A screen at each station so nobody has to walk over to ask.

The system already exists before you write a single line of code. It's just running on paper, and memory, and people walking across rooms.

Your job isn't to invent a system. It's to see the one that's already there — and the only way to see it is to go stand in the room.

I've never regretted the week I spent watching. I've regretted every system I built without it.