Yonder

Inspiration

We're students at Rutgers University, and we kept running into the same problem. We'd cross town to play basketball and every court would be taken. We'd show up at a café to find a line out the door, or at a store to find the thing we wanted sold out. Maps are great at telling you where a place is. They can't tell you what's happening there right now.

Then we thought about who that gap hurts most. If you use a wheelchair, a broken elevator at a subway station isn't an inconvenience. It decides whether the trip is possible at all. The person who could answer that question is often already standing right there.

So we built Yonder: ask someone who's already there, before you make the trip.

What it does

Ask. Pick a place on the map, ask one specific question ("Are any basketball courts free?"), and choose how long it stays open.
Choose how you want to know. An answer that's a day or more old is free. For a new one, you post a bounty of $2 or more, and you're only billed if someone actually answers in time.
Scout. Someone nearby, a Scout, gets a short checklist of what to look for. Photos are taken live in the app, never uploaded from the camera roll. Scouts keep faces and private details out of frame, and they can skip anything that feels unsafe with no penalty.
Get an answer you can trust. Every answer is labelled self-reported and shows exactly how old it is.

Accessibility is built in as a core check: "Is the step-free entrance or elevator working?" Live checks have no charge during early access.

Yonder Plus is an optional subscription for people who check a lot. It gives longer check windows (up to 2 hours), more open checks, and unlimited collections of saved places.

How we built it

App: Expo SDK 57, React Native, Expo Router and TypeScript. Native maps on iOS and Android, with a Leaflet preview on web.
State: Zustand with local persistence. This powers a fully labelled demo mode: a sample NYC tour with 12 places, so anyone can try the whole ask → Scout → answer loop.
Backend: Supabase Auth, Postgres and row-level security for live place checks. Requests are created, claimed, answered, released, reported and cancelled through database functions, so the rules live on the server, not in the client.
Subscriptions: RevenueCat for Yonder Plus. The app loads offerings and prices from RevenueCat, buys and restores through the SDK, and listens for entitlement changes. A RevenueCat webhook syncs the yonder_plus entitlement into Postgres, and the database is what enforces the longer check windows. The app never just trusts itself.
Tests: unit tests for pricing, purchases, auth and navigation, plus a disposable-Postgres test suite for the database policies.

The billing rule is simple. When you post a bounty, it has a deadline. If a Scout answers before the deadline, you're charged the bounty and the Scout is paid out from it. If nobody answers in time, nobody pays.

Freshness is just as explicit. Every answer shows how long ago it was observed, like "12 min ago", and once an answer is 24 hours old, it becomes free for anyone to view.

Challenges we faced

Trust is the whole product. One fake answer could cost someone a trip. We designed every screen around honesty:
- answers are labelled self-reported;
- every answer shows its age;
- sample content is labelled "Example answer · not live";
- demo payments say so on screen.
Safety by design. Asking about places, never people, meant building in:
- public-place confirmation;
- no-faces capture rules;
- an always-available "skip" for Scouts;
- reporting and blocking.
Server-side entitlements. RevenueCat webhooks usually arrive within seconds to a minute, not instantly. We had to design a "Confirming Plus on Yonder's server…" state, instead of claiming something the server hadn't confirmed yet.
Small details that matter. App stores often express a one-week trial as "7 days", so we normalize trial periods to read "1 week free". We also reworked several screens so the key information fits on one iPhone screen without scrolling.
Keeping up with a moving platform. Expo SDK 57 changed enough that we worked from the versioned docs for every API we touched.

What we learned

The hardest part of a two-sided app isn't the code. It's making both sides feel safe and treated fairly. The asker should only pay for an answer they actually got, and the Scout should never feel pressured into an unsafe situation.
Putting business rules in the database (row-level security and database functions) made the app simpler and harder to cheat.
RevenueCat let us treat subscriptions as an entitlement, not a one-off purchase screen. Plus status follows the account across devices, restores cleanly, and is enforced on the server.
Accessibility can be a main feature from day one. It doesn't have to be bolted on later.

What's next

Proving live checks with real Scouts on our campus, turning on real bounty payments and Scout payouts, and growing from basketball courts and cafés to every place where a quick look before you go makes the trip better.

Yonder. Go with confidence.