Social media · Consumer app · 2024 · In production

StrangerUs

A social app that shows who’s checked in at nearby venues, so strangers can chat and then meet in person.

0:43

of check-ins start a conversation: 74%
check-ins at partner venues: 12k
of chat requests get accepted: 58%
to screen 1,000 posts with AI: $0.40

The problem

People in the same café pass each other without a word, and no app showed who nearby was open to meeting right then. Venues wanted those walk-ins to come back as regulars.

Who it’s for: People in Singapore who want to meet others at cafés, bars and events nearby, and the venues that host them.
My role: AI/ML and backend engineer
Team: 4 people: backend, web, mobile, design
Timeline: Since March 2024

Stack

AI

OpenAI GPT-4.1 mini
LangChain

Backend

NestJS
PostgreSQL
TypeORM
Socket.IO
Zod

Integrations

Firebase Cloud Messaging
Google Maps Platform
Cloudinary
App Store Server API
Google Play Billing

Apps

React Native
Next.js

Infra

Docker
Render
Jest

How it works

Clients

Mobile app
Venue dashboard
Venue QR code

Edge

REST API
Socket.IO gateways
AI moderation

Services

Check-ins
Match score
Chat
Store billing

Data

PostgreSQL
Expiry cron

Providers

OpenAI
Firebase push
Google Maps
App stores

Step 01 / 06

A guest scans the venue’s QR

The token is single-use and stored only as a hash; an optional geofence can also require the phone to be near the venue.

Step 02 / 06

Check-in opens a timed session

It expires at two hours, closing time or the event’s end, whichever comes first; a cron checks people out every minute.

Step 03 / 06

Everyone in the room updates

When someone checks in or out, the Connects socket tells each checked-in phone to re-fetch who is there.

Step 04 / 06

Each stranger gets a match score

Shared interests weigh 60%, networking preferences and languages 15% each, age and country 10%. Admins can retune the weights without a release.

Step 05 / 06

AI screens what people post

Profile text, photos and venue listings go to GPT-4.1 mini with a structured verdict schema before anything is saved.

Step 06 / 06

Chat confirms real delivery

Messages travel over the socket and Firebase push; a tick turns double only when the recipient’s device acknowledges that message.

Decisions

Fail closed on moderation

Chose Refusing the write with a 503 when the moderation model can’t be reached over letting unchecked content through.

On an app that introduces strangers, an unscreened photo costs more than a retry.

Trade-off: An OpenAI outage blocks profile, photo and venue edits until it recovers.

Ticks mean the phone has it

Chose Marking a message delivered only when the recipient’s device acknowledges its ID over inferring delivery from socket presence or an accepted push.

Presence isn’t receipt: senders kept a single tick after the recipient’s push had already arrived.

Trade-off: Every app build must send acknowledgements, over HTTP or the socket, before ticks turn double.

Keyset paging for chat history

Chose A keyset cursor on sent time and message ID over offset paging or a timestamp-only cursor.

Offsets skip or repeat messages while new ones arrive, and timestamps can tie. A chat now opens on its newest 40 messages.

Trade-off: Clients lose total message counts and can’t jump to an arbitrary page.

What I’d do next

I’d run the test suite in CI from the first week. We wrote 490 tests, but nothing ran them on every pull request.
I’d log every moderation verdict with its category and latency, so the prompt is tuned on data rather than on complaints.
I’d design chat receipts and history paging before launch; both were reworked in September 2026, nearly two years after launch.

Results

Check-ins that start a conversation
Before: 21%After: 74%
Sent messages stuck on one tick
Before: 14%After: 2%
Time to open a long chat
Before: 2.4sAfter: 0.3s
Profile and photo reports a week
Before: 38After: 9