DestinyPair
Christian Singles Community Platform
DestinyPair is a Christian singles community platform designed for people seeking meaningful relationships, serious connections and marriage-focused community. It is the largest product I have shipped and the one that pushed me furthest as an engineer, because the difficulty was never the profile grid — it was identity, trust, discovery and the paid-intent workflow behind a relationship product.
Technology
The problem
Dating and community products usually fail on the unglamorous parts. Profiles are created and then abandoned halfway. Discovery returns a grid of everyone rather than a filtered set of people worth meeting. Trust signals are missing, so the people who are genuinely serious are indistinguishable from the people who are not. And there is no clean path from "interested" to "committed" — no way to move a free member to a paid subscription without losing them in a payment redirect.
Approach
- 01
Treated the product as an identity system first. Authentication had to be forgiving enough for real users (social sign-in alongside email) but strict enough that a profile actually means something, so profile completion became a first-class, measurable state rather than a cosmetic percentage.
- 02
Modelled the domain as separate Django applications with explicit ownership: accounts, profiles, discovery/matching, subscriptions and messaging. Keeping these boundaries meant a change in matching logic could not quietly break a payment callback.
- 03
Made discovery a server-side decision. Filtering, compatibility scoring and ordering run on the backend so the React client is a thin renderer and the rules stay testable and portable.
- 04
Designed the subscription path as a workflow rather than a button: intent, checkout, verification, entitlement. Every state is server-authoritative, so a user cannot reach a paid feature by manipulating the client.
- 05
Kept the frontend a responsive React application so the same product works on the phones people actually use to meet people.
Architecture
- 01
Identity
Email and social sign-in create a single account record. Sessions stay server-authoritative, and every downstream feature reads the user from that one source.
- 02
Profiles
Profile creation is staged, with completion requirements driving what a member can do next. Partial profiles are a state to be recovered from, not a dead end.
- 03
Matching & discovery
Compatibility logic and filtering run server-side. The API returns an ordered, scoped set of candidates; the client only presents them.
- 04
Subscriptions
Payment workflow with server-side entitlement state. Access decisions are made from recorded subscription status, never from what the browser claims.
- 05
Messaging
Direct messaging between permitted pairs, scoped so conversation is only possible once the platform rules allow it.
- 06
Administration
An admin surface for managing users, reports and platform state — the operational requirement that most hobby builds skip and every real product cannot.
Feature modules are separated by responsibility, but the through-line is the same: the server decides, the client renders.
Key features
Challenges
Making a profile mean something
A relationship platform breaks down when profiles are half-finished and everyone is still shown to everyone. I made profile completion a gated part of the domain model so the rules live in one place, and every screen asks the same question: what is this member allowed to do right now?
Trust and paid intent
The subscription path had to survive redirects, abandoned checkouts and repeat visits. Entitlement is derived from server-side subscription state, so a returning user sees the same access regardless of how they arrived.
Matching rules that could actually be maintained
Compatibility logic started inside the view layer and became unmaintainable fast. Moving it behind a service boundary meant the rules could be changed, reasoned about and reused without touching the API surface.
What I learned
Product engineering is mostly state management. Almost every hard bug in a social or marketplace product traces back to two things disagreeing about what state a user is in. Modelling that state explicitly on the server removed most of them before they existed.