SIDE QUEST LABS
devlog — issue 02

Palate wasn’t supposed to be social

It started as a private, offline food journal. It became a follow-gated dining graph — dish-level reviews, an invite system tuned by hand, and a hard rule about who gets to see what.

August 13, 2026 Palate 5 min read

The brand doc that kicked this off pitched a quiet, personal thing: a local-first log of restaurants you’d visited, offline by default, shareable only when you felt like it. Tavern was the working name — cozy, low-stakes, a catalog for yourself. Palate won out instead, and somewhere in the build the whole shape of the thing changed with it.

Places tab with live map and nearby restaurant cards
Feed tab showing reviews from accepted follows
You tab showing profile stats and review history
The verdict screen for rating and tagging a dish
Places · Feed · You · The verdict

Screens above are running against seeded sample data in the simulator, not a live backend.

From journal to dining graph

The single-player version didn’t last. Palate is now a social dining journal: you log the dishes you eat — rating, notes, tags, a reorder intent, a photo — and follow the people whose taste you trust to see what they order. Following is approval-gated, so nobody sees a review until they’ve accepted your request. Restaurant and dish identity are shared across everyone; opinions stay private to your follow graph.

That one rule — public facts, private opinions — ended up shaping almost every screen. A restaurant page always shows the aggregate rating; the individual reviews underneath are either there or replaced with a locked state, depending on whether you follow the person who wrote them.

What’s built

Five tabs’ worth of behavior, all running local-first against a schema shaped to match a future Supabase backend field-for-field — swapping in a real backend later is a service-layer change, not a model rewrite.

Onboarding
Invite-gated, Sign in with Apple, ending on a working profile with a starter allotment of invites.
Places
Live map and search, MapKit-backed and deduped, with the visibility rule made visible on every restaurant page.
Logging a dish
Pick an existing dish or create one, rate it, tag it, photograph it, mark it a reorder — edit or delete later.
Feed
Reverse-chronological reviews from accepted follows, with a dismissible strip for pending requests.
You
Your own review history, shaped identically to how everyone else sees you — not a separate journal view.
Finding people
Username search, invite links, and on-device phone-contact matching — nothing leaves the device to find a match.

The details that took longest

Auth

Sign in with Apple, verified end-to-end

Provisioning confirmed clean, real sign-in tested and working on a physical phone. The debug “skip sign-in” button that stood in during early builds is gone — the real thing is now the only door in.

Search

The search dropdown, redesigned

First pass was a boxed card under the search bar. Second pass de-boxed it into hairline rows in one solid panel, added a match-count footer past four rows, and highlighted the matched substring in each name — small, but it’s the screen you touch most.

Invites

Invite cap, tuned by hand

Started as a hard, non-renewable 3-per-user cap with an open “exact number TBD” comment sitting in the code. Landed on 5 starter invites that refill weekly — used 2 of 5, you get topped back up to 5, not stacked on top.

What’s deliberately not there

A few calls worth writing down so they don’t get re-litigated later:

  • No public Explore feed. Discovery stays follow-based only — contacts, username search, invite links, and “who else reviewed this place.”
  • No dedicated Log tab. It lives in the “+” button in the top bar instead — a fourth tab for it was proposed and turned down.
  • No push notifications for follow requests. A badge dot only — state comes to you when you open the app, not before.

What’s next

  1. A “want to try” wishlist — bookmark a place before you’ve eaten there, distinct from a post-visit review.
  2. Editing your profile after onboarding — avatar, display name, and username are currently set once and never again.
  3. A manual “add a restaurant” flow for places Apple Maps doesn’t surface.
  4. Food-themed invite codes, instead of a random 6-character string.

Questions about this build?

I’d be glad to hear what stood out, what you’d change, or what you’d like covered next.

Send a note

Opens your email app.

Back to all quests public facts, private opinions