← All case studies
CASE STUDIES · 2024-2025

Offlinery

Real-time, sub-second matching on hostile mobile OSes, built end-to-end.

Offlinery was a dating app built against swipe culture. A proprietary matching algorithm surfaced nearby people who actually wanted to meet in person. Shipped on iOS and Android. Wound down in 2025.

AI 2024-2025 Wind Down
01 Overview

Overview

Offlinery was a dating app built against swipe culture. A proprietary matching algorithm surfaced nearby people who actually wanted to meet in person. Shipped on iOS and Android. Wound down in 2025.

02 The Challenge

The Challenge

Surface the right nearby person inside a minutes-long window so a real-world approach actually happens. Two compounding constraints: a proprietary algorithm doing sub-second proximity and mutual-intent filtering, and reliability against iOS and Android killing background tasks the moment they lose interest.

03 The Call We Made

Continuous, accurate location, while the screen is locked.

Getting continuous, accurate location from a locked phone is brutal. The OS shuts background processes down to save battery. The privacy model nags the user every time matching needs to fire. Stay accurate against an OS actively suppressing you, and keep the prompts honest enough that users still say yes.
04 What We Did

What We Did

Both phone OSes actively suppress real-time matching. We designed every layer around motion-driven triggers, smart deferral, and graceful degradation, fallback path ready before the OS pushes back. Proprietary proximity engine on PostGIS. React Native + Expo with hardened background geolocation, push, error tracking, i18n. NestJS + TypeORM backend with JWT, throttling, transactional email and Expo push. Full App Store and Play Store releases. Sub-second proximity on a moving phone, on hardware that didn't want to cooperate.

05 Outcomes

Outcomes

Scale Real-time Proprietary Matching Engine
Scale Sub-second Proximity Queries
On Reel
Promotional trailer.
In-app demo.
Architecture & Flows

Production infrastructure

Backend, Postgres+PostGIS, analytics and logs on Google Cloud. Waitlist on Vercel. Sentry for crash reporting, MailChimp for transactional mail.

The diagram illustrates a simplified high-level architecture and omits confidential implementation and security details.

Match notification flow

sequenceDiagram
  autonumber
  participant U as User App
  participant API as NestJS API
  participant DB as PostGIS
  participant N as Expo Push
  U->>API: location heartbeat
  API->>DB: find nearby candidates
  DB-->>API: matches (geo + filters)
  API->>N: notify both users
  N-->>U: silent push
Heartbeat → proximity query → mutual push. Background geolocation drives the loop; the API stays stateless.
06 What We Learned

What We Learned

Real-time in-person matching lives or dies on signals the OS actively kills. Half the work is algorithm, half is platform fight. Motion-driven triggers, smart deferral, graceful degradation, fallbacks when accuracy gets capped. On a moving phone, speed and resilience are the same problem.

Tech Stack
Tags
AI / MatchingReal-time GeoMobile App

Want outcomes like this?

Tell us what you're building. We'll tell you whether we're the right team for it.

 Book a call