Show, Don't Tell: Shipping a Restaurant-Deals MVP in Two Days
An idea is easy to describe and hard to believe. A working thing you can hold in your hand does the convincing for you. Here's the two-day build that taught me to stop pitching and start shipping.
Every restaurant runs two inventories at once. There's the food in the kitchen, and there's the empty table in the dining room, and both spoil. A seat that goes unsold at 8 p.m. on a Tuesday is gone forever, the same way a tray of prepared food is gone if no one orders it before close. Most of that loss is invisible because it never shows up as a line item; it just quietly evaporates every night.
I wanted to build something that turned that evaporating capacity into demand. The idea was simple: a phone app that detects where you are, finds the restaurants near you running a promotion right now, sorts them by distance, and lets you grab the coupon. Restaurants fill seats and move product that would otherwise be dismissed for lack of customers; diners get a deal a few minutes' walk away. Two problems, one match.
That's the part that's easy to write in a sentence. The hard part is getting anyone to feel it, and that's where most ideas die.
The problem with describing an idea
If I had brought that paragraph to someone as a pitch, I know exactly how the conversation would have gone. Nodding. "Interesting." A few questions about the business model. And then nothing, because a paragraph asks the listener to do all the imagining. They have to build the app in their own head before they can react to it, and most people won't spend the energy.
A working demo flips that. When you hand someone a phone, let them tap "find deals near me," and watch a list of nearby restaurants populate with real distances, there's nothing left to imagine. The idea stops being a description and becomes a thing that exists. Reactions get instant and specific, "what if it filtered by cuisine," "could the restaurant set the discount," "this is basically X but for restaurants", and those reactions are worth more than any amount of upfront discussion, because they come from people responding to something real instead of something hypothetical.
So I decided not to explain the idea. I decided to build enough of it to put in someone's hand, and to do it before the idea got cold.
Two days, boring tools
I gave myself a weekend, which meant the technology choices made themselves. This was not the moment to learn a new framework or chase the most elegant architecture, it was the moment to reach for tools I already knew well enough to move fast in:
- Ruby on Rails for the application. Rails' whole philosophy (convention over configuration, scaffolding, sensible defaults) is built for exactly this: getting from an empty folder to a working CRUD app in hours, not days.
- PostgreSQL for the data. Restaurants, promotions, locations, a handful of related tables. Nothing exotic.
- JavaScript and AJAX for the interaction. The "find deals near me" experience has to feel live: read the browser's geolocation, send the coordinates, get back a sorted list, update the page without a full reload. AJAX kept that snappy.
- Geolocation and distance math to turn "where am I" into "what's near me, closest first."
None of these are impressive choices, and that's the point. The goal wasn't a beautiful system. The goal was a working one, fast.
The piece that made it real: ngrok
Here's the gap nobody warns you about. You can have a perfectly working app running on your laptop, localhost:3000, responding to every tap, and it's still useless for showing anyone, because it lives on your machine and nowhere else. The classic answer is "deploy it," but deploying a two-day prototype to a real host, with all the configuration that implies, can take longer than building the thing did. That friction is exactly where momentum dies.
ngrok erases it. It opens a secure tunnel from a public URL straight to the app running on your laptop. One command, and localhost:3000 becomes a real link anyone can open, including on their own phone, with their own location, walking around their own neighborhood. No deploy, no server, no DNS. The prototype on my machine became something I could text to someone and say "open this."
That's what turned a local experiment into a demo. The geolocation actually mattered when the person holding the phone was somewhere real, not when I was faking coordinates at my desk.
What the two days actually bought
The app was rough. It was a prototype, not a product, and it was never meant to be more than that. But the two days bought something a polished pitch deck never could: it made the idea arguable. People could disagree with it, improve it, or dismiss it on the merits, because there were merits to react to, instead of a hypothesis to be polite about.
That's the lesson I kept. The cost of a two-day prototype is almost nothing measured against the clarity it produces. A demo collapses weeks of "what if it worked like…" conversations into ten seconds of "oh, that's what you mean." It de-risks an idea by making it concrete enough to test against reality early, while changing direction is still cheap.
I build very different systems now, larger, more careful, with real architecture and real consequences. But the instinct underneath is the same one this restaurant-deals app taught me: when you want someone to understand an idea, don't reach for more words. Reach for the smallest working version you can put in front of them, and let it do the talking.
Show, don't tell. It's much easier to show an idea than to tell about it, and it always will be.
If I built this today, the bones would be the same, boring, familiar tools chosen for speed, but I'd likely swap the demo step for a one-click preview deploy, or keep ngrok for the genuinely instant, on-your-own-phone version. The framework changes. The bias toward shipping something real doesn't.