Forkers

Turn empty restaurant seats into new dinner companions — meet travelers and locals over a shared table.

Comment

The Problem

Loneliness is now treated as a public-health crisis. The WHO links it to about 871,000 deaths a year, and Japan has appointed a Minister for Loneliness. Japan's own data points straight at the dinner table: people who rarely share meals are about four times as likely to often feel lonely. Most don't eat alone by choice — their timing just doesn't line up with anyone else's. There's no pill for loneliness. The cure is people — and an open seat at a table.

Across the street, restaurants sit through slow hours with empty seats. Squeezed by rising costs, a record 900 restaurant operators in Japan went bankrupt in 2025 — when margins are that thin, every empty seat counts.

Inspiration

Traveling alone in Europe, I wanted a casual meal with locals and fellow travelers in Denmark. Dating apps serve a different purpose, and event-based apps like NomadTable had too few options for communal meal. Back in Japan, living alone, I'd often skip dinner out rather than sit solo among couples and groups.

Existing apps miss that moment. Timeleft matches strangers once a week at a restaurant it picks. Soroyoi (そろよい) finds solo-friendly restaurants but doesn't get you a shared table. Neither helps when it's 7pm, I'm hungry, and I don't want to eat alone tonight — and neither helps restaurants turn empty seats into revenue.

What it does

Forkers connects diners who don't want to eat alone with restaurants that have seats to fill.

  • Diners browse live tables nearby by distance, time, and cuisine, join solo or with friends, chat with the table beforehand, then meet to share the meal. Limited featured spots per area and time slot is a real scarcity that makes a featured table worth competing for.
  • Restaurants post open tables for free. To fill a slow Tuesday or a big table, they pay a small one-time fee to Feature this slot, moving it to the top of Discover with a highlighted "popular" badge.
  • RevenueCat powers that purchase. It's classic marketplace logic: free to join, pay only for visibility. As more restaurants compete for the same diners, featuring becomes a habit, not a one-off.

Joy grows where people keep showing up. Forkers isn't built for one good night out — it's built to make coming back a habit, until a booking becomes a small community. Travelers carry it home: they join a table abroad, then open one in their own city. The community grows one table, one city at a time.

How I built it

I'm a product designer, and frontend developer — I built Forkers with Claude Code as my engineering partner. The app runs on Expo/React Native with Supabase, where security and data rules are enforced by the database itself rather than trusted to the app. RevenueCat handles the in-app purchase, and a database check makes sure each purchase features exactly one table.

I kept the MVP tight — Google/Apple sign-in only, table chats that expire after the meal, and hand-onboarded restaurant partners — so the time went into the one thing that had to be rock solid: a purchase flow restaurants would trust with real money.

Challenges I ran into

  • A security bug: one purchase could be reused to feature a second table for free. I fixed it at the database level so each purchase unlocks exactly one table, then re-tested the full flow.
  • A launch crash: a late build crashed on startup with no clear cause. The app was identifying the user to RevenueCat before RevenueCat had finished starting up. After fixing the startup order and adding crash logging, I confirmed zero crashes across 25 cold launches.

Accomplishments I'm proud of

Shipping a complete, App Store–compliant app solo before the deadline: account deletion, reporting and blocking, and a purchase flow tested with real sandbox transactions on a real device. That testing even caught a RevenueCat sandbox quirk where a stuck earlier test made a successful purchase look cancelled — something code review alone wouldn't find.

What I learned

Design decisions I felt sure about — chat retention, when a table counts as "full," how blocking works — kept revealing new edge cases once tested against real scenarios. One turned out to be a real security hole. My process now: propose, then pressure-test before calling it final.

What's next

  • Scale restaurant onboarding beyond manual verification
  • A map view, plus instant alerts when a nearby table opens
  • Japanese localization for restaurant partners, then expansion beyond one city
  • Turn "Feature this slot" into a recurring option for restaurants that want standing visibility — the path from one-off purchases to predictable subscription revenue

The goal: make the second, third, and tenth dinner feel natural. That's where both the community and the revenue compound.

Built With

  • async-storage
  • eas-build
  • expo-apple-authentication
  • expo-blur
  • expo-image
  • expo-image-picker
  • expo-location
  • expo-notifications
  • expo-router
  • expo-secure-store
  • expo.io
  • google-sign-in
  • hermes
  • nativewind
  • postgresql
  • react
  • react-native
  • react-native-purchases
  • react-native-reanimated
  • revenuecat
  • supabase
  • supabase-edge-functions
  • supabase-realtime
  • supabase-storage
  • typescript
Share this project:

Updates

Submission history