← All work
RestouriSEARCH RESTAURANTS BY CRAVING
Marketplaces & consumerLiverestouri.com

Restouri

A meal-first restaurant discovery app for Jamaica — you search by dish or craving ('oxtail', 'curry goat') and it shows the dishes and the kitchens selling them, not just restaurant names.

1,555+
restaurants, all 14 parishes
Search a dish
not a list of venues
Works offline
installs like an app

The problem

Restaurant apps make you start from the restaurant. Hunger is specific — you want oxtail, not a list of venues. Restouri makes the dish the thing you search for.

What it does

One search matches dishes and restaurants together: 'oxtail' returns priced menu items across kitchens plus a separate list of places. Dishes are first-class records — name, price, tags, availability — with their own ranking and favourites, not metadata hanging off a restaurant. A 'Pick fi mi' feature rolls a real backend endpoint honouring your filters when you can't decide.

It installs like an app, keeps working with a shaky signal, and signs you in without a password. Restaurant owners get their own app to claim and update their listing, with new claims reviewed before they go live. The catalogue covers roughly 1,555 restaurants across all 14 parishes; when you're ready to order, it hands off to the restaurant's WhatsApp.

Key features

  • Search by craving, not by name

    You want oxtail, not a directory of venues — so you search the dish and get priced options nearby, instead of guessing which restaurant might have it.

  • 'Pick fi mi'

    When you can't decide, it picks for you — honouring your filters — so indecision doesn't end in cooking at home.

  • Owner-claimed listings

    Restaurants claim and maintain their own menu and prices, so what you see is current rather than a stale third-party guess.

  • Works on a real Jamaican afternoon

    Installs like an app and keeps working on a patchy signal in bright sun, so discovery doesn't fall apart the moment the network does.

  • Order over WhatsApp

    Ordering hands off to the number the restaurant already uses, so there's no new checkout for either side to learn.

Under the hood — for the technically-minded

How it's built

The whole thing is organised around making the dish, not the restaurant, the primary object. Dishes are first-class records — name, price, tags, availability — with their own ranking, favourites and search weight. A pnpm monorepo splits a consumer PWA and a partner app (both React Router) from a Fastify API over Postgres with PostGIS for location, and Redis for sessions and rate limits.

It's built for the real conditions it runs in: an installable, offline-aware PWA, light-only, tuned for a mid-range Android phone on a patchy signal in bright sun. Ordering deliberately hands off to a restaurant's WhatsApp rather than an in-app checkout — checkout is an explicit non-goal for v1.

The hard problems

  • Search that works before a single owner types a menu

    Meal-first discovery is useless with an empty catalogue, so the catalogue seeds itself: restaurants are tagged by what they're known for as they're ingested, and real dishes are extracted automatically from menu photos — so a search returns priced dishes from day one, before a single owner has typed anything.

  • Owners can take over their own listing safely

    Listings are pre-seeded, then owners claim them through a workflow that prevents two people claiming the same kitchen and holds each claim for admin approval before it goes live.

  • Passkeys, hardened before launch

    Sign-in is passkey-first across the consumer app, partner app and API, and was tightened after the team's own adversarial security review added an email-verification step before a passkey can be set up.

Built with

  • React Router 7
  • Fastify
  • Postgres + PostGIS
  • Passkeys
  • PWA

Building something in this space?

Work with us →