About the project
A values first dating app where photos stay hidden and uncover tile by tile as two matched people actually talk, built with React Native over a vector search backend.
My role: Product and technical design, then full stack development of the mobile app, the API and the matching data model.
I built Soulsinq around a deliberate inversion of how dating apps work. Everywhere else the photo is the entry point and everything else is secondary, which trains people to judge in a quarter of a second. Here the photo starts fully hidden behind a grid of twenty five tiles, and tiles only lift as two matched people genuinely interact. Attraction is not removed from the equation, it is simply moved after the conversation instead of before it.
That premise dictates the data model. Matching cannot rely on images, so it runs on values, stated preferences and proximity. I used PostgreSQL with two extensions doing the heavy lifting: PostGIS for geographic filtering and pgvector for similarity search over value profiles, both accessed through Drizzle with typed schemas. A shared package holds the zod schemas and constants used by client and server alike, so a change to a profile shape breaks compilation on both sides rather than surfacing as a runtime bug in production.
The mobile app is React Native on Expo with expo-router, and the API is Express running on Firebase Functions second generation. Keeping the API as a plain Express application rather than a set of individual function handlers meant I could run it locally against a Docker Postgres and test it through the Firebase emulators, which kept the feedback loop short while the product design was still moving.
Main features
- 🧩 Progressive photo reveal: A profile picture sits behind twenty five tiles that lift only as two matched people genuinely interact.
- 🎯 Values based matching: Compatibility is computed from declared values and preferences rather than from appearance.
- 🧠 Vector similarity search: pgvector compares value profiles inside PostgreSQL, so matching stays a database query instead of a separate service.
- 📍 Geographic filtering: PostGIS narrows candidates by real distance before any similarity work happens, which keeps queries fast as the base grows.
- 📱 One codebase for iOS and Android: React Native on Expo with expo-router ships both platforms from a single navigation tree.
- 🔗 Shared contract between app and API: zod schemas live in a shared package, so a profile change breaks compilation instead of production.
- 🧪 Fully local development: Docker Postgres with PostGIS and pgvector plus the Firebase emulators reproduce the whole stack offline.
- ⚙️ Express on Cloud Functions: Keeping a classic Express application rather than isolated handlers made the API testable end to end in one process.
Problems and solutions
Problem: Dating apps put the photo first, which trains people to decide in a fraction of a second and buries everything a profile actually says. Simply hiding photos does not work either, because users abandon an app that feels like it is withholding something from them.
Solution: The photo is present from the start but covered by a grid of twenty five tiles that lift as the conversation progresses. Nothing is withheld, the reveal is simply earned, and matching meanwhile runs on values compared through vector similarity rather than on appearance.
