Humraah

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.

This is client work for Third Shade Media, so there are no product screenshots here. What follows is the architecture, the code, and the decisions, all of which are mine to show.

Express 5 on Node with Mongoose 9: 13 route files, 23 services, 26 models, eight node:test suites. The Expo app is TypeScript with expo-router, SecureStore for tokens, and expo-screen-capture so chat and biodata screens cannot be screenshotted. Thirteen external integrations: SurePass for Aadhaar and DigiLocker, Gallabox for WhatsApp templates and the bot, Razorpay on web plus Apple IAP and Google Play Billing in the app, Firebase and APNs for push, Resend for email, Cloudinary for private media, Google Places with an OLA Maps fallback, Groq for the FAQ chatbot, Tesseract and pdf-parse for biodata extraction.

The PWA is plain HTML, CSS and JavaScript served from Hostinger rather than from WordPress itself, after plugin conflicts kept breaking the app pages. The app was rebuilt screen by screen against the website as the source of truth, which surfaced a whole class of React-Native-Web bugs (auth headers on images, Alert callbacks, FormData) that the web client never had. The backend does not know which client is calling except through an ApiMetric middleware that records platform and UTM for the admin analytics.

• Security first (30 June to 5 July). Strict JWT auth replacing the localStorage token, helmet, hpp, mongo-sanitize, rate limiting; user images moved to private Cloudinary behind an authenticated route; admin auth hardened; release builds stopped logging profile status.
• Matching. Compatibility scoring, family-exclusion rules so members of one family group are never matched (with FamilyGroup, FamilyExposure and FamilyEvidence models and a test script), pair eligibility, 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 (MediaPipe), Google Places addresses proxied and cached server-side, Aadhaar via SurePass with a deep-link return for native and duplicate-Aadhaar recovery, payment gate, email verification.
• The notification policy engine. Twenty-five event types over four channels with opposite eligibility rules. One policy file decides; every channel enforces it a second time. More below.
• Moderation and the match journey. A four-level moderation engine scoring thirteen violation classes, report and block with a permanent-block privacy model, the five-day supervised chat with photo-request gating, and the Meet/No decision after chat expiry.
• The app (24 July to 12 September). Expo and React Native from scratch: design system, every screen, push end to end with platform-aware payloads and a 28-entry deep-link table, Aadhaar on device, Play Store UGC compliance (reporting, blocking, moderation), a reviewer sign-in path, in-app purchases on both stores.

Three delivery channels, three opposite rules. WhatsApp is for members who are not yet live: it carries the six registration-recovery reminders whether or not push works, because a family that has not installed the app still needs to be told their payment is due. Email is for members who are live, and only to an address they verified, so an optional email can never become a registration drop-off. Push goes wherever a token exists. Members can mute intros, mutual interest or chat, and the mute is a substring match on the type name.

That last detail is how I found the first bug: muting chat also silenced chat_closed_decision and chat_meet_confirmed, the two moments the whole five-day window exists to produce. The second bug was structural. profile_verified, the “your profile is now live” message, was only fired when the status was active, and the WhatsApp gate required the status not to be active. An approved template with one variable, configured, and unreachable for every member by construction. payment_success and profile_rejected had the same shape: a member pays ₹499 and, without a push token, is told nothing on any channel.

The fix is three explicit allow-lists in notificationPolicy.js with the reasoning written above each one, and a flag threaded through to the WhatsApp sender, which re-checks the status on its own and would otherwise drop the message the policy had just allowed.

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.

What I would do differently: the chat is REST polling every four seconds rather than a socket, and the cron jobs run inside the API process, which is fine for one Render instance and wrong for two. Both are on the handover list, with the reasoning.