Naksh.

The matrimonials category — choosing a life partner, with family and verification in the mix — is poorly served by the swipe model the consumer‑dating world standardised around. The signal in a profile is too sparse; the incentives push toward an infinite feed of low‑effort impressions; the people who use it for the thing it claims to be for end up exhausted by it.

Naksh is the version that would work better. Three to seven curated introductions per day, scored against a thirty‑six‑point compatibility framework with profile, family context and verification. The scarcity is the feature.

Everything here is mine: the app, the API, the matching framework, the verification flow, the brand, the website.

iOS. Swift and SwiftUI throughout. Daily introductions, profile and verification flow, compatibility detail.

Backend. Node.js services and Postgres. The compatibility scoring runs server‑side; profile and family data sit behind verification.

Verification. Identity verification and the family‑context flow that distinguish Naksh from the swipe‑app category it shares a shelf with.

Web & brand. trynaksh.com live as the marketing surface and the waitlist while the iOS app is in App Store review.

Fig. V.B–C The thirty‑six‑point scoring lattice and the daily‑set selection function that turns it into the 3–7 introductions per day.

• 01Website live. trynaksh.com is the marketing surface and the waitlist.
• 02iOS in review. App submitted to App Store review.
• 03Single‑engineer scope. A non‑trivial consumer iOS product taken from zero through to submission by one person.
• 04Framework reuse. The compatibility framework and the verification flow are reusable surfaces I can carry into other consumer work.