Inspiration

I moved to Leytonstone three months ago. I don't know anyone here.

London is big enough that the people I do know live more than an hour away. You can't build the kind of bond that comes from being in the same place again next week when "next week" means crossing the city after work. As an adult, the friendships that feel real are the ones you don't have to schedule.

Before I wrote a line of code I spent 1 week reading the threads where people already complain about this. r/Leytonstone, r/london, r/AskUK. The same question kept appearing in different words: how do you make friends as an adult in London when everyone you know already has their people? That's not a problem an event feed solves. It's a problem repetition solves.

But a neighbourhood can connect people who happen to share a postcode. The bartender at the local doesn't need to be in your phone. The Sunday quiz crowd doesn't have to live on your street. Showing up at the same place three weeks in a row is its own kind of belonging, at least, that's the bet I'm testing.

The apps I tried first weren't built for the question I actually had. Meetup wants me to keep picking new events. Eventbrite is transactions: buy a ticket, go, never go back. Bumble BFF makes friendship a swipe. Timeleft hosts strangers for dinner once. None of them help with the only thing that builds belonging: showing up at the same place next Sunday until the bartender recognises you.

I'm not a regular anywhere yet. That's why I'm prototyping Belong.

The strange part: just talking to the people testing it has already started doing the work. Building the prototype is making me of the neighbourhood while I'm still building it. That's not a metric, but it's the first sign the bet might be right.

What it does

Belong is an early prototype with a clear hypothesis: that someone who just moved to a London neighbourhood is better served by becoming a regular somewhere local — at one place, recurring, walking distance — than by another feed of one-off events.

Instead of picking events from a feed, you answer six short questions and Frankie (the host character I built into the chat) suggests one existing weekly activity. Not a list. One. The deal is: go there. Go again next week. The bartender starts recognising you.

What the prototype tries deliberately not to do:

  • No streaks
  • No push notifications
  • No 4am scrolling — the app refuses to render between 00:00 and 05:00 local time

I'm not sure that all four constraints will survive contact with real users at scale. But naming them upfront is part of the test.

The prototype currently has two neighbourhoods sketched out (Leytonstone E11 and Hackney E8) with around 27 weekly activities I've researched and tagged. Adding a third would be straightforward; what's hard is verifying that the activities are actually still happening, which is something no LLM can do for me (we verify the information online recurrently, but some activities change offline).

There's also a small B2B side: a venue can claim its listing at /v/[slug] and update it. If a bartender changes the karaoke time, anyone looking at the activity page sees the new time within a second (Firestore onSnapshot under the hood). That's the bit that felt most "real product" to build.

How we built it

Built solo over three weeks of evenings.

Frontend. Next.js 16 (App Router, Turbopack) on Vercel. React 19. TypeScript. Tailwind CSS v4 with custom design tokens. The visual register is intentionally editorial — Fraunces for headings, a single Mango accent, no gradients, no sparkles — because I wanted it to read as a small publication rather than a SaaS dashboard.

Frankie. Anthropic Claude Sonnet 4.6 via a server-only /api/chat route. The system prompt is filtered by the user's neighbourhood so Frankie can't recommend a Hackney quiz to a Leytonstone resident. Voice rules in the prompt are explicit: no LLM warmth, no "try this!" optimism, recommend one thing or none.

Backend. Firebase (Firestore + Anonymous Auth + Email Link Auth). The cross-device recovery — finding a user's data on a new device by matching their email — took two iterations to get right.

Maps. MapLibre GL with OpenFreeMap tiles. No vendor lock-in.

Analytics. Pendo via Novus.ai, with about 23 tracked events. I'm not sure I'll keep them if this stays a side project, but during the hackathon they were useful for debugging the demo flows.

Realtime sync. The B2B → B2C path is a Firestore onSnapshot listener.

Challenges we ran into

The cross-device sign-in case. Someone signs up anonymously on their phone, upgrades to email auth, then opens the app on a laptop. First version lost their data because the laptop session was a new anonymous UID. I had to query Firestore for any user doc matching the email and re-attach. The Firestore rules to allow that lookup while keeping reads scoped to the user took two passes.

Frankie's voice. The architecture was the easy part. Writing a system prompt that consistently produces lines like "You've had three good Sundays at The Old Crown. Don't pile on Saturday yet" instead of generic LLM warmth took a lot more iteration than the code did. Every time a test reply sounded off-character I rewrote a section of the prompt.

Magic links in spam. My own first test magic link landed in my spam folder. Firebase's free tier doesn't allow customising the email body, only the from-name and subject. I worked around it by tightening those, but the limits of free email auth were a real lesson.

Outreach is harder than code. A week in, I realised the bottleneck wasn't features — it was getting a single venue to say "yes, you can mention us." Code ships in commits. Pubs reply on Instagram when they reply. The prototype felt real the moment one said yes.

Accomplishments that we're proud of

A demo that's the actual app, not a mockup. Every screen in the submission is the real prototype running in a browser. The realtime split-screen is one continuous take. The chat replay is one continuous take. No After Effects.

A point of view I'm willing to defend. Most apps in this category optimise for engagement. This one specifically doesn't. I built a NightGate that refuses to render between midnight and 5am because the alternative is trying to compete with TikTok for late-night attention, which is a fight I'd lose and shouldn't want.

Research that isn't fabricated. Every activity in the catalogue came from the venue's own website, social, or my walking past in person. The ones I haven't been able to confirm are flagged as unverified, with copy that says "call the venue before you go." Honesty over completeness.

One actual yes. The pub manager at The Old Crown replied to my Instagram this weekend saying they're happy to be featured. One yes from one venue is small, and it's the difference between an idea on a slide and a prototype with a foothold in the real world.

What we learned

Voice is the architecture. I spent more time on the five-line opening of Frankie's system prompt than on any component. That decision sets the ceiling for everything downstream.

Honest copy beats polished copy. The line "We haven't independently verified this one yet — call ahead before you go" feels stronger than any version that hedges with marketing-speak. Honesty reads as care.

A small idea can have a wedge. I wasn't sure a hackathon prototype could have a point of view until I named what it won't do (streaks, push, 4am) and watched people respond to that more than to the features.

The act of building can be the first instance of the product working. I moved here three months ago not knowing anyone. The reason I have a yes from The Old Crown is that I walked up to their Instagram and asked. That's literally what Belong is meant to make easier for everyone else — and it works on me first.

Reading the people already complaining is the cheapest user research that exists. Two weeks of Reddit threads told me more about the actual shape of the problem than any survey I would have run. Belong is what you'd build if you took those threads seriously instead of building another feed.

What's next for Belong

Here's what I'd test next, in the order I'd actually prioritise — not a pitch deck.

More venues that have said yes. One is a start. Three or four across two neighbourhoods would tell me whether the venue-side proposition is a real thing or just a nice idea.

A way to keep activity info honest at scale. Right now I personally check each listing. That doesn't scale beyond ~30 activities per neighbourhood. Some kind of lightweight "is this still happening?" loop with venues or trusted regulars seems unavoidable.

Frankie remembering across sessions. Today each conversation starts fresh. Persisting the last few turns per user would let Frankie say "last week you said you didn't love the run club" without the person having to remind him.

Tool use, so Frankie can actually book. Right now the chat reads as a host but the booking action lives on another page. Giving Frankie a book_activity tool would close that loop — and it's the natural way to test whether a conversational booking flow holds up at scale.

Built With

Share this project:

Updates