Flagship product
The Caribbean food guide
New York never had.
Hundreds of curated Jamaican and West Indian restaurants across the five boroughs and Long Island, with real photos, must try dishes pulled from customer reviews, live distance from where you are standing, and an AI guide who knows the difference between a roti shop in Richmond Hill and a jerk spot in the Bronx.
The food is everywhere.
The information is nowhere.
Caribbean food discovery in New York is scattered across Google Maps, Instagram, delivery apps and word of mouth. Google buries the small spots. Delivery platforms only show you what pays to be shown. None of them understand the difference between Trinidadian doubles and a Jamaican patty, or which bakery has the good hard dough.
The result is that the best food in the city is the hardest food to find, and the businesses serving it are the least visible online.
One platform, built for one community.
Not a generic restaurant app with a different colour scheme. A dedicated discovery platform where every listing is curated, every photo is owned, the dishes worth ordering are surfaced, and the assistant on top actually understands the culture it is describing.
The data pipeline, the AI context architecture and the product itself were built from scratch, for one community, by one studio.
What we built
Two native apps, at parity.
iOS in SwiftUI. Android rewritten in Kotlin and Jetpack Compose at full feature parity, sharing design tokens, cuisine and dish catalogues and an identical assistant prompt, so the product behaves the same whichever phone you hand it to.
Discovery
- Borough filters across NYC and Long Island
- Near Me sorting from live GPS
- Top rated and recently added
- Search across restaurants and dishes
- Curated Best Restaurants shelf
The listing
- Owned photography, served from our storage
- Must try dishes extracted from real reviews
- Editorial badges awarded through human review
- Open and closed state, ratings, review counts
- Exact distance from the user
Beyond the list
- Full map view with every pin
- Favourites
- Caribbean Passport, islands unlocked as you explore
- Errol, the in app food guide
- Restaurant owner claim and verification flow
Coverage
Every listing, plotted.
The map is the fastest way to understand the catalogue. Pins cluster by area and break apart as you move, so a borough holding hundreds of spots reads as clearly as a corner of Long Island holding nine.
Filters apply to the map and the list together. Island cuisine, dish, borough, open now and near me all narrow the same result set, and the count at the bottom always reflects what you are actually looking at.
The assistant
Meet Errol.
Errol is the Caribbean food guide built into the app. He knows the catalogue, he knows which places are open, and he knows what to order. He speaks the way the community speaks, and he knows when not to.
The part that matters is where his answers come from. An assistant working from general knowledge will answer questions about a restaurant from what it assumes rather than what the listing says. That is a real risk when you put one in front of the people who pay you.
Errol is designed to stay grounded in verified YardLink Eats data. Relevant listings and their precomputed distances are retrieved and placed in context before a recommendation is generated, so answers are built from the catalogue rather than from assumption.
How the grounding works. The user location is injected into the system prompt at request time, with distances to every restaurant precomputed before the call. Errol answers from that context, which is why he can name a nearby matching spot and tell you roughly how far it is.
We build assistants like this for other businesses. Your brand, your voice, your data, your customers. A restaurant, a barbershop, a clinic, a hotel. If people ask you the same questions all day, we can build something that answers them in your voice, around the clock, grounded in information you have approved. See how
On Android
Same product, rewritten native.
Android is not a wrapper around the iOS build. It is a full rewrite in Kotlin and Jetpack Compose, sharing the design tokens and the assistant prompt so the two stay honest with each other.
The Android build is a full rewrite in Kotlin and Jetpack Compose at feature parity, sharing design tokens, the cuisine and dish catalogues and the same assistant prompt as iOS. We are not publishing Android screenshots here until we have captured a fresh set from the current build, because a stale screenshot is worse than none.
The key never ships in the binary
The assistant runs behind a serverless proxy. The API key lives in the server environment, so it never touches the app binary and cannot be recovered by reverse engineering a release build.
Enforced at the database
Firestore security rules let a client read the catalogue and submit an ownership request, but never publish, edit or approve. The pipeline runs the Admin SDK and is the only thing that can grant anything.
A photo loads once, not once per scroll
A two layer image cache in memory and on disk, automatic fallthrough when a photo reference expires, dead references remembered per session, and a branded tile as the final fallback.
The stack
What it is made of.
- SwiftUI
- Core Location
- Firebase SDK
- Shared LocationManager
- Kotlin
- Jetpack Compose
- Firebase SDK
- Shared design tokens
- Firestore
- Firebase Storage
- Security rules
- Python and Flask pipeline
- Claude API
- Netlify Functions proxy
- Google Places API
- Anonymous auth
The hard parts
What actually took the time.
Photos that cost money every time you look at them
Places photo references are metered and they expire. Fetching on demand means paying repeatedly for the same image and showing a blank tile when a reference dies. The fix was to copy each photo once into our own storage, sync the URL back to the record and own it permanently, so the app never re-fetches and never re-bills.
An assistant that had to be structurally honest
Prompting a model to be careful is not a guarantee, so the catalogue became the context instead. The assistant receives the relevant real records and their precomputed distances at request time, which is what keeps recommendations anchored to listings that actually exist. Grounding became an architecture decision rather than a wording decision.
Verifying restaurant owners without collecting documents
The owner platform uses a verification ladder. An owner proves control of the phone, email or website already published on their listing before any document is requested. It is the pattern Google Business Profile uses, and it means the common path stores no documents at all.
Reads that quietly multiply
The editorial surface polled the full collection on a short interval, once for the stats and again for the list. Sharing a single collection read between both endpoints cut Firestore reads by roughly forty times without changing what the reviewer sees.
Otonia
Want something like this built?
Apps, data pipelines and grounded AI assistants. Tell us what your business needs.