Humraah
Matrimonial platform. Backend, PWA and mobile app taken from a failed audit to store review
Measured
| Metric | Value | Window | Source |
|---|---|---|---|
| Blocking audit findings, 35 fixed, 5 accepted as non-blocking; localStorage auth, public image URLs, missing spec features | 40 → 0 | 30 Jun to 12 Sep | All_Issues.md and launch QA register F-01…F-30, 12 Sep 2026 |
| Backend commits, the rest by one teammate | 355 of 363 | Jun to Sep 2026 | git shortlog -sn, humraah-backend, 12 Sep 2026 |
| Mobile commits, Expo app built from scratch | 155 of 155 | Jul to Sep 2026 | git shortlog -sn, humraah-mobile, 12 Sep 2026 |
| Pre-registrations, founding-member list before launch | 500+ | Sep 2026 | Third Shade, 14 Sep 2026 |
Problem
Humraah is a private, family-first matrimonial service: Aadhaar-verified profiles, up to three curated introductions a week, photos hidden until the chat stage, a five-day supervised family chat, and a guarded path from YES/NO/LATER to mutual interest, biodata and a Meet/No decision. When I joined in late June the product looked finished from the outside. An audit on 30 June found forty issues, including auth that lived in localStorage, user images on public URLs, and features from the spec that did not exist. The brief became: make it real, then take it to the app stores, on one backend.
One backend, three clients
What I built, in order
- Security first (30 June to 5 July). Strict JWT auth, helmet, hpp, mongo-sanitize, rate limiting; user images moved to private Cloudinary; admin auth hardened; release builds stopped logging profile status.
- Matching. Compatibility scoring, family-exclusion rules so members of one family group are never matched, separate pools for first marriages and new journeys, a daily match-feed job.
- Registration. WhatsApp OTP, resumable drafts, a gender-based photo policy with on-device face detection, Aadhaar via SurePass with a deep-link return for native, payment gate, email verification.
- The notification policy engine. Twenty-five event types over three channels with opposite eligibility rules: WhatsApp only before a profile is active, email only after and only to a verified address, push whenever a token exists. One policy file decides; every channel enforces it a second time.
- Moderation and the match journey. A four-level moderation engine, report and block with a permanent-block privacy model, the five-day supervised chat, and the Meet/No decision after chat expiry.
- The app (22 July to 12 September). Expo and React Native from scratch, every screen rebuilt against the website as source of truth, push end to end, Aadhaar on device, Play Store UGC compliance, reviewer sign-in, in-app purchases on both stores.
Before and after
Where it stands
Google Play: bundle 1.0.0 (5) on internal testing, listing and every content declaration done, the ₹499 one-time product active in 169 regions; the only step left is finance attaching a bank account and pressing rollout. App Store: build 1.0 (8) in TestFlight, version page and App Privacy complete, blocked only on the Paid Apps Agreement. Thirty-five of forty QA register items fixed, the rest documented as non-blocking. Client work: product screenshots are intentionally omitted, so this case study covers the architecture, the engineering decisions, security, release engineering and the measured outcomes instead.
Learned: One backend, three clients, and every notification channel has its own rules.