Background
Brandon started PlatePost after noticing the same thing across restaurants. Most menus are a name and a price. Customers order from a short description and whatever picture that puts in their head, and the food that arrives is often nothing like it.
He wanted the menu built around video instead. Scan a QR code at the table or tap the tablet by the register, and see the actual dish before ordering.
I joined in April 2024 as the designer. Over the next twenty-one months I built the VideoMenu template and designed a version of it for each restaurant, starting with WYWH Coffee in Pomona and ending with APE Coffee Orange.
One system, six restaurants
Every restaurant got its own VideoMenu. Same product underneath, different surface.
Three things stayed fixed across all of them: the item modal, the category navigation, and the footer. A customer who had used one PlatePost menu already knew how the next one worked.
The food card was a master component, but it never shipped the same way twice. Each restaurant came in with its own brand, and the menu had to feel like theirs rather than like software they had rented. So the typeface, the colors, and the chips were set per restaurant. APE Coffee Orange is black and white with a two column split. Cafe Yoto runs monospace on a four column grid with photo icons for categories. Irv's uses flat primary color blocks behind every product shot. MakiMaki runs a three column grid, black text on white, with a photo beside every item.
Each one took two to three days.
Designing for each restaurant
Every restaurant brought a problem the template didn't already answer.
WYWH Coffee runs three services out of one shop. Coffee all day, brunch in the morning, cocktails at night. One menu with all of it means someone who came in for a coffee is reading a cocktail list they have no use for. So WYWH opens on a choice instead of on food. Three cards, one per service, with the hours under each. You pick where you are in the day and go from there.
MakiMaki Sushi had no photos for a lot of the menu. The sake, the beer, the tea, none of it was shot, and the restaurant wasn't going to shoot it. On a menu built around images that's a problem, because the obvious thing is to leave a grey box where the photo should be. Instead those items drop the image entirely and run as a plain list with a name and a price. The section still looks finished.
Cafe Yoto serves Japanese food under Japanese names. Kinoko Donburi, Karaage Udon, Wakame Kyuri. I've been the person staring at a menu in a cuisine I don't know, working out how to say something without getting it wrong, and usually giving up and pointing. I added a speaker button to each item that plays the name said properly. I built it with Claude and Gemini, wired it in as custom code, and used Google's text to speech with phonetic spellings so the names came out right instead of read as English.
Kei's menu is long, so we gave first-time customers somewhere to start. Best sellers came from the cafe's own numbers. For staff picks we asked the people working there what they actually liked.
The Kei discovery
Kei Coffee House was the second restaurant. The menu showed a photo, a name, a description and a price for each item, and that was all it did. Nothing on the card was tappable, and nothing on it suggested otherwise.
Brandon was in the shop during the first week of the pilot, watching people use it. Almost everyone tapped the card anyway. It was card shaped, so they wanted to see what would happen. Nothing did.
We got on a call and I changed two things. The whole card became a tap target, opening a modal with the video at the top and the item details underneath. I also added a small arrow to the corner of each photo so people could tell the card did something before tapping it.
The food card was a master component, so both changes went to every restaurant, not just Kei.
Where I wanted it to go
The template solved the ambiguity problem. You could see the food before you ordered it. But the menu still stopped at looking, and I thought it should do more.
So I designed a second version using Kei's menu and put it in front of Brandon. Category navigation became photo chips instead of text. A Click to Order button took you to Kei's Toast page, so the menu could end in an order instead of a decision you had to repeat at the counter. Items carried the Best Seller and Staff Picks chips directly on the card, instead of only in a row at the top of the menu.
Two things went further. An AI Suggest Pairing button, which took whatever you were looking at and suggested something to go with it. And a panel under each item with calories, macros and ingredients.
Brandon liked it. It never went into the template.
The nutrition panel was the part I was least sure about. I designed it, then hit the question of where the data would come from. A cafe changes recipes constantly and we had no way to keep it accurate. I raised it with Brandon. I don't know whether that fed into his decision, and V2 never went into the template either way.
The Kei pilot
We ran a four week pilot at Kei from August 25 to September 21, 2025 to see whether the VideoMenu changed anything.
Kei tracked scans and orders and sent the raw numbers over. Brandon did the analysis. Across four weeks there were 5,798 scans against 26,836 orders, so about one in five customers opened the VideoMenu. The target was one in four.
Average order value came out at $16.09 across the pilot, against $16.05 before it started, a number Kei pulled from their own system. Brandon's model put that at $946 of additional revenue over the four weeks. It's worth being clear about how that was calculated, because it applies the difference in average order value to every order, including the roughly eight in ten that came from customers who never scanned. A cleaner test would compare orders where someone scanned against orders where nobody did, and I don't know whether Kei's system could split it that way.
We also sent a survey to the front of house staff to find out whether the system got in their way. I never saw the results.
What I take from it is that people used it, and we couldn't prove much beyond that.
The app I wanted to build
Menu content lived in Framer's CMS rather than in the page, so a new restaurant took days instead of weeks. Every update after launch came through me though. If a cafe added a seasonal drink or changed a price, I made the change. That was fine at six restaurants. It would not have scaled.
We had three or four restaurants when I brought up the app. I thought PlatePost should be an app, not a set of websites.
The idea was one app with every partner restaurant in it. Same VideoMenu, but you could order from it, and there would be rewards for coming back. A customer who used it at one cafe would find the next one already in there. Websites can't do that. Every restaurant is its own island.
Brandon disagreed. Three or four restaurants isn't a directory, it's a list, and an app with four places in it gives someone no reason to keep it installed. Build the client base first, then the app.
He was right about the timing. I still think we should have started earlier. Adding restaurants to an app is a database row, and the work of building it doesn't get easier by waiting. We had fifteen by the time I left.
What I'd do differently
Start the app sooner. Brandon's reasoning about client count held up, and I agreed with it at the time. But the app was never going to get easier to build, and adding a restaurant to it would have been one row in a database. Waiting for the client count to justify it meant we never started.
And ask the measurement question before the pilot rather than after. Whether Kei's system could separate scanned orders from unscanned ones decided what the pilot could prove, and I only worked that out once the numbers came back.
Brandon has since built a tool that lets restaurant owners update their own menus.