Dindy

Dinner for six shouldn’t be 12 Angry Men. Everyone swipes. Dindy turns votes into one optimal order, flags restrictions upfront, dodges “I don’t eat that,” predicts cost, & cheekily reads the room.

Comment

Inspiration

Three years ago, on 30 September 2023, I brought my laptop to a group dinner.

The problem is simple. More restaurants serve plates meant for sharing, and I have always loved eating family-style. Sharing is wonderful, but it turns ordering from an individual decision into a group one, and groups have no good way to make it. The loudest person picks. Or everyone is so polite that twenty minutes go by with the server hovering. And the person with a dietary need has two bad options: explain it to the whole table, or stay quiet and eat what's left.

That last one became personal when my seven-year-old nephew was diagnosed with celiac. He took it in stride. My mom doesn't eat fish. I've had dinners with pregnant friends who didn't know how to navigate the menu and didn't want to announce it yet to the table.

So before that dinner in 2023, I found the restaurant's menu online, turned it into a swipe-style survey, and made a QR code. Everyone scanned and voted. I pulled the results into a prepped Excel sheet, sorted by votes, and read the order to the server. It was ridiculous, and it worked. I ran it at 18 dinners for more than 200 people. Afterward people would say, "that was the perfect order." When I didn't have time to set it up, friends asked, "why don't we have Dinnder tonight? This is so much harder." (It's Dindy now.)

The biggest test was my own wedding. We ran the menu past all 136 guests the same way, and the results changed what we planned to serve. That's when I realized this isn't only about dinner with friends. Any time one person chooses food for many people (a wedding, a business dinner, an event, a catering order), they are guessing. Dindy replaces the guess with a solution.

Two ideas shaped it. From Priya Parker's The Art of Gathering: the best hosts practice "generous authority," taking charge on the guests' behalf so everyone else can relax. And a character I love, the Sloane Ranger host: the person who has you completely taken care of and is a little wry about it, witty with an edge but never mean. Dindy is meant to be that host.

Diners already want one. From the 2025 Resy Retrospective:

  • 72% of diners say a "Table Captain" (whoever takes charge of ordering) improves the meal.
  • More than half of Gen Z diners have invited someone to dinner specifically for their ordering expertise.
  • 94% say they're likely to share their meal when dining out.
  • 90% of Gen Z diners enjoy communal tables.

Dindy gives every table a Table Captain without anyone having to be the bossy one.

Underneath it is something I care about: so much of life is stuff we slog through. I'd rather make it fun.

What it does

  1. One person starts a table. Everyone joins with a link, a QR code or a six-character code. Guests install nothing; they can swipe in a browser.
  2. Everyone swipes the real menu, privately. Right for yes, left for no, down to skip, double-tap for the one dish you love (exactly one each, so it means something). The deck is the menu verbatim: every dish in the restaurant's printed order, with sizes and prices.
  3. Dindy ranks the dishes. Each dish $d$ scores across the table:

$$\text{score}(d) = \sum_{i=1}^{n} w\big(v_i(d)\big), \qquad w(\text{love}) = 2,\; w(\text{yes}) = 1,\; w(\text{skip}) = 0,\; w(\text{no}) = -1$$

Dishes with no "no" votes and strong support earn a "the table's in" badge, so the group only debates the contested middle.

  1. Dindy sizes the order by dish type, not just votes. A large plate counts as one serving, a small plate a half, a side a third, targeting roughly 1.3 servings per person. It walks the ranked list, takes one of each top dish, then adds seconds of the favorites until the table is fed; never more than three of anything. Desserts and drinks are never added automatically.
  2. A server view shows the final order in large type to hand to the waiter.
  3. The Tea gives everyone an AI-written read on how they ate: a moniker for the night, a horoscope-style take on their picks, their Taste Soulmate, their Menu Nemesis, and one line on the table as a whole. Built to be screenshotted.

What the dietary flags do, and don't do. You mark what you avoid once, on your profile. Pregnancy has its own section, because it's a life stage with its own list, not a diet. Dindy then flags conflicting dishes for the whole table before anyone orders, and never says whose need it is. The Taste Soulmate and Menu Nemesis use votes only, never dietary data, and The Tea jokes about food choices only, never bodies or health. For my nephew that means nobody has to announce anything: the table sees which dishes don't work, and he scans flags instead of reading every description line by line. Flagged dishes stay visible unless you hide them; nothing is silently removed. Flags are advisory, built from menu information and what diners tell us, so you still confirm with the kitchen. Dindy solves the social problem, not the medical one.

How it looks and feels

I started from the categories Dindy sits between. Delivery apps are red, photo-grid, transactional. Dietary apps are clinical, green, medical. Dindy goes the other way: playful, kinetic, one dish at a time, set in type on a single confident color.

  • System: cobalt #2233C8 ground, butter #FFE270 as the only accent, hand-weight line art, one typeface — Bricolage Grotesque. The accent marks exactly one thing per screen: what you'd do next.
  • Voice: the Sloane Ranger host. Cheeky, never cheesy. The in-app tagline is "start a food fight."
  • Process: I worked with a local designer on initial brand sketches and took her and her husband to dinner to test the app. I also ran Meta ads to test different looks, each asking one qualifying question, so the leads told me who actually has this problem.

Accessibility, deliberately:

  • White on cobalt is 8.8:1; deep cobalt on butter is 9.3:1. Text passes WCAG AA everywhere.
  • The swipe stamp tracks your finger, so direction is obvious even if you've never used a swipe app. Undo is unlimited and you review every pick before submitting, so a wrong-way swipe costs nothing.
  • The server view uses large type, readable at arm's length in a dim room.
  • Guests join from a browser, so nobody at the table installs anything to take part.

How I built it

  • App: React Native (Expo) and TypeScript. Guests use the same app on the web.
  • API: Fastify and tRPC on Google Cloud Run, Postgres on Cloud SQL, Firebase phone sign-in.
  • AI: Gemini 2.5 Flash on Vertex AI. Photograph any menu and two passes turn it into a deck: the first extracts every item verbatim in printed order, the second tags dietary conflicts conservatively, flagging when uncertain. Gemini also writes The Tea.
  • Payments: RevenueCat. One consumable, dindy.tea.table, served from the default Offering as package tea_table. The app renders the price from the Offering; nothing in the binary knows what $6.99 is.
  • Entitlements live in our database, keyed by table, not per-user in RevenueCat. That single decision is what makes one purchase unlock five other people's accounts. No per-user entitlement model expresses it.
  • We never trust the client. Our API asks RevenueCat's v2 API whether the buyer really owns that transaction before unlocking anything. A unique index guarantees one purchase unlocks exactly one table. RevenueCat's NON_RENEWING_PURCHASE webhook is the backstop if the app dies mid-purchase, and CANCELLATION revokes on refund.
  • Someone outside the team proved it works. During App Review on 29 September, the reviewer signed in, swiped all twelve cards on our demo table, and bought the table's Tea at 14:30 UTC. RevenueCat recorded it, our server verified it before writing, and the unlock landed against that table: one row, one transaction id. The app was approved minutes later.
  • Quality: four rounds of independent AI code review before release. Round one surfaced two blockers; the last three found none.
  • Process: solo, alongside AI coding agents. 123 commits over 18 working days from 11 July 2026.

Challenges, and what each dinner taught me

I tested every major change at a real restaurant dinner. Each one changed the product.

  • Bar Terroir: the order was monotonous. The top-voted dishes for two were oysters, salmon crudo, another raw fish and a cold salad. Every pick popular, the meal together dull. The same happens when everyone loves the fried appetizers: you still don't want five. A variety nudge that swaps in a contrasting dish when it's nearly as popular is next on the list. Votes will always win when the table clearly prefers something.
  • Bar Terroir again: the payoff sat behind the wrong button. The Tea only appeared after someone confirmed the order. I confirmed to see mine, then my husband re-confirmed to see his. Confirming is shared; seeing your read is personal. I separated them.
  • Lumbre: nobody saw The Tea at all. Still behind "order confirmed": and at a real table the waiter takes the order, not the app. The Tea is now reachable the moment you finish swiping.
  • Cosme: the dietary picker was built for the wrong list. Diners wanted to avoid cilantro, so the AI now tags it. Pregnancy moved to its own section. The picker was tightened to one screen.
  • Loves had to be personal. The first version gave the table a shared pool of three. Each person now gets exactly one.
  • Names that only make sense to the builder. A first-time tester didn't know what "See the Tea" meant. The button now says what you get: "Who ordered like you?"
  • Small real-world details. A dark QR code on cobalt doesn't scan in restaurant light, so it sits on a white tile. A solo diner was once told to order two entrées, so sizing rounds to the nearest serving instead of always up.

What I learned

At the first app dinner, four people went from sign-in to a confirmed order in 3 minutes 32 seconds, swiped 48 of 48 cards with no drop-off, and ordered nine dishes that were exactly the top nine by score. A later table swiped all 36 cards: 100% completion.

People don't mind swiping a whole menu if it feels like a game and ends with something about them. The Tea is that ending. Before building it I tested the idea by sending friends a link with a few questions and having AI roast them. They screenshotted their results and passed them around unprompted.

Two numbers tell me whether this works: order adherence, the share of top-voted dishes that reach the final order, and repeat hosting, the share of hosts who start a second table within 30 days.

Business model

Why one-time, not subscription. Group dinners are occasional, so a monthly charge is the wrong shape. Before pricing I benchmarked nine comparable social apps (Gas, NGL, Co-Star, Lapse, Locket, BeReal, Partiful, Beli, Timeleft). Two lessons: subscriptions sold on curiosity lose trust fast, and gating the core experience kills the loop. Swiping, voting and ordering are free forever; only the read-out is paid. An annual pass for frequent hosts is worth testing later.

Why "buy the table a round" works.

  • People who spent money on others ended the day happier than those who spent the same on themselves — and most predicted the opposite (Dunn, Aknin & Norton, 2008; replicated 2022). Because people underestimate that feeling, framing matters: The Tea is a gift to the table, not a personal unlock.
  • People act more generously when others can see it (Ariely, Bracha & Meier, 2009). Buying The Tea happens in front of everyone, and every phone lights up at once.
  • Eating from shared plates makes people cooperate more than eating from separate ones (Woolley & Fishbach, 2019), and eating the same food builds trust (2017). Family style is already cooperative; The Tea lets one person turn it into a small gift.
  • At a table of six, $6.99 is $1.17 a head.

How many tables buy. If each diner has probability $p$ of being the one who pays, a table of $n$ buys with probability:

$$P(\text{table buys}) = 1 - (1 - p)^{n}$$

RevenueCat's 2026 benchmark puts median freemium conversion near 2.1%. That figure measures per-user lifetime paywall conversion rather than one diner at one dinner, so it isn't a like-for-like input; I use it as an anchor and treat $p$ as an assumption to be replaced with our own data. On that anchor: roughly 8% of tables of four, 12% of tables of six, 16% of tables of eight.

Market ceiling, conservatively. No public dataset counts group sit-down dinners, so here is the model with every assumption labelled, using the low case throughout:

Input Value Source
US adults ~260 million US Census
Planned dine-outs per month ~10 OpenTable 2026
Diners likely to share their meal 94% Resy 2025
Share of adults at a group sit-down dinner in a month 10% (low case) Assumption
Diners per group table 6 Our dinners; OpenTable 6+ trend

That is 52 million group tables a year in the US — a ceiling of about $44 million a year from The Tea alone, before any other line. What matters more is the near term:

Tables/year on Dindy Penetration Tables that buy (12%) Gross at $6.99 Net after Apple's 15%
10,000 0.02% 1,200 $8,388 $7,130
100,000 0.19% 12,000 $83,880 $71,298
520,000 1% 62,400 $436,176 $370,750

One percent of the conservative case is a $370,000 business on one product.

And the base case understates reach. A study of 800,000+ transactions at a Norwegian restaurant chain found a mean party of 2.44 and a median of 2: most restaurant tables are small. Dindy is built for the sharing table, but a two-top is a real use case too: a first date deciding what to split, two friends catching up. Group dining for parties of six or more grew 11% in 2025 (OpenTable). We are sized for the growing end and useful at the common one.

Beyond The Tea. The Tea is the first revenue line, not the only one:

  • Weddings, events and catering. My wedding showed the same vote works at 136 people. Planners, caterers and companies hosting business dinners all choose food for groups without asking them. A paid event tier, priced per event, is the natural next product.
  • Restaurant insights. Every table records what groups chose, skipped and loved. Aggregated and anonymized, that is demand data restaurants don't have: which dishes groups want, which never get ordered, which pairings win. A dashboard subscription follows.
  • Industry trend data. The same aggregate shows food and beverage brands how group tastes shift, dish by dish and city by city. Personal data and dietary needs are never sold or attributed.
  • Restaurant-sponsored rounds. A restaurant buys The Tea for its tables: the digital version of sending over dessert.
  • Point-of-sale integrations such as Toast, so the order reaches the kitchen directly.

Experiments ready to run. Sibling products at $4.99 and $9.99 are created in App Store Connect and ready to submit. Because the price comes from the RevenueCat Offering, a price experiment needs no app release.

Growth loop

Every Dindy dinner is a group activity, and everyone takes part to get their vote in. A table of $n$ puts the app in front of $n - 1$ people who didn't start it. With $h$ the share of those guests who later host, and $s$ the new hosts each table brings in through shared Tea cards:

$$K = (n - 1)\,h + s$$

At a table of six, five guests see Dindy. If one of the five goes on to host, that is one new dinner per dinner before counting anyone who arrives through a shared Tea card. These are the numbers I am measuring now.

Why restaurants should like it

Tables decide faster — 3 minutes 32 seconds at our first dinner. The order is sized up front, so fewer late "we didn't get enough" rounds stretch the meal, which should mean quicker turns. The server view hands the waiter a clear written order, cutting misheard dishes. Expected benefits, not yet measured.

What's next

  • Translation of menu items For those who are traveling.
  • The variety nudge from the Bar Terroir dinner.
  • "What tables on Dindy loved most" per restaurant, built from our own votes; the best server in the room.
  • A next-day question: "what was the best thing you ate?" One tap, and every answer sharpens recommendations.
  • Restaurant insights and point-of-sale integrations, then Android.
  • Events mode for weddings, business dinners and catering, where one planner collects votes from a whole guest list.

Dindy went live on 29 September 2026. Three years, near enough to the day, after I carried a laptop to dinner to solve this by hand.

About me

Six years in strategy and analytics at Barry's, where I ran Barry's X, the brand's digital fitness app. Maths and psychology at Northwestern; MBA from Harvard Business School. Dindy is built under my own company, Chesherie. The goal is simple: everyone gets a say, nobody sits out the meal, and the table leaves knowing each other a little better.

Sources

Built With

Share this project:

Updates

Submission history