Jain Parichay: from a PDF-sharing tool to a full matrimony platform

Jain Parichay is a matrimony service, and I was the software developer who built and ran the software for it. The group started back in 2019; I built the website during college in 2024 and kept it running and growing, later starting the v2 rewrite. The live version (v1) serves real monthly traffic, and I managed all of it myself — the code and the infrastructure.

There are really two generations of it, and they’re quite different, so I’ll walk through both honestly.

v1 — circulating biodata PDFs

The first version (live at jainparichay.in) solves one job well: sharing biodata profiles as PDFs. An admin logs in with Google, picks a folder from Google Drive, and the backend generates a share link. Behind that link, the app crawls the Drive folder, syncs the PDFs to my own S3-compatible storage, and serves them through a PDF viewer with range-request streaming so pages load as you scroll. Admins can invalidate or refresh a link when profiles change, and there are small helpers like PDF merging.

It’s an Express/EJS app on Redis, with Google OAuth and the Drive integration doing the heavy lifting. Nothing fancy — but it did exactly what Jain Parichay needed.

v2 — a real matrimony platform

The next version — v2, which I started building at v2.jainparichay.in — was a ground-up rewrite into a proper product: a NestJS/Astro monorepo with a typed tRPC API (17 routers), around 20 PostgreSQL models via Prisma, phone-OTP auth over Twilio, and Razorpay payments. It has the things a matrimony platform actually needs: profile search, interests/matches, messaging, verification, and trust-and-safety (reporting, blocking, privacy controls).

The piece I’m most proud of is the automated biodata-import pipeline. Someone can hand us an existing biodata PDF and we turn it into a structured profile:

1. A Temporal workflow discovers the PDFs and processes each one durably.
2. A LangGraph state machine runs the steps: OCR (Azure Document Intelligence, with a local pdftotext/Tesseract fallback) → structured extraction with OpenAI GPT-4o-mini under a strict Jain-biodata schema → photo extraction → persist the profile, with duplicate detection by phone/email.

biodata PDF → Temporal workflow
            → LangGraph: OCR → GPT-4o-mini extract (schema-enforced) → photos → Postgres profile

There’s also a notification engine I built for SMS, WhatsApp, and email (English and Hindi), using a Postgres-backed job queue so it doesn’t need any extra infrastructure, plus Sentry and Prometheus for visibility. It all runs as Docker services, and I managed the VPS, domain, networking, and reverse proxy myself.

Being honest about scope

A couple of things I’ve described elsewhere more loosely, so to be precise: v2 doesn’t do PDF compression/optimization — that was a v1-era idea, and what actually ships is the Drive→S3 sync and a fast viewer. And while there’s design work toward a mobile app, the mobile app itself isn’t built yet. I’d rather say what’s real than what’s planned.

What I took away

This was the project where I owned the code end-to-end for a long time, as the developer for a live product with real users. It taught me the difference between shipping a feature and maintaining a product — migrations, uptime, backups, and knowing when a rewrite (v1 → v2) is worth it. The biodata-import pipeline is also the clearest example I have of using LLMs for something genuinely useful: turning a messy PDF into a clean, structured profile without a human retyping it.