I built shadibiodata.com — a marriage biodata maker for Indian families. This isn't a post about the product. It's about the specific technical decisions I made around AI, where they paid off, and where I overcomplicated things for no reason.

Quick context if you don't know what a marriage biodata is: it's essentially a one-page resume used in Indian arranged marriages. Name, education, career, family background, photo. Very common, very important culturally, and almost everyone was still making them in Word 2012.

The tech stack before I get into it: Next.js + TypeScript frontend, AWS Lambda for backend, DynamoDB, S3, CloudFront, AWS Bedrock for AI, PostHog + Sentry for monitoring.

The Problem I Was Actually Trying to Solve With AI

I want to be clear about this upfront: I wasn't trying to "add AI" to the product. I was trying to solve two specific problems that I couldn't solve cleanly without it.

Problem 1: India has 22 officially recognized languages. A family in Maharashtra wants their biodata in Marathi. Their profile on the matrimony site is in English. The WhatsApp share going to the groom's family in Nagpur needs to be in Hindi. Same document, three languages, one click ideally.

Problem 2: I had 10 templates and users were freezing. Classic paradox of choice. They'd click back and forth for minutes and sometimes just leave. I needed something to narrow it down for them without adding a lengthy quiz.

Both of these had obvious AI-shaped solutions. The harder part was making them actually work.

AI Translation: The Prompt Engineering Rabbit Hole

The naive implementation is obvious — take the form data, send it to an LLM, ask it to translate. Done in an afternoon.

Except it's not done, because the output is wrong in a dozen subtle ways.

The first version I shipped would translate someone's name "Priya Sharma" into its literal Hindi meaning. It would reformat dates. It would translate "B.Tech Computer Science" into something that sounded like a Hindi description of the degree rather than keeping it as-is. And cultural terms like "Gotra" (a Hindu clan identifier) were getting translated into vague approximations that would confuse anyone who actually knows what Gotra means.

The prompt went through probably fifteen iterations.

The Template Recommendation Logic

This one was simpler than I expected but I still overthought it initially.

My first instinct was to build something clever — maybe a vector similarity search across template metadata, or a small classifier trained on user choices. I was genuinely considering fine-tuning something.

Then I stepped back and thought about what information I actually had:

Religion (Hindu / Muslim / Christian / Sikh / etc.)
Language preference
Whether they'd described themselves as "traditional" or "modern" in a one-question onboarding step
Region (derived from city input)
And what I actually needed: narrow 10 templates down to 2-3 that this specific person would likely prefer.

The current implementation is embarrassingly simple. It's essentially a rule-based scoring system: each template has tags (traditional, modern, minimal, royal, south-indian, muslim, etc.), and the user's profile maps to a weighted preference vector. Top 3 scores win.

No LLM involved. No API calls. Just a lookup.

I mention this because I think there's a tendency (and I had it) to reach for AI when simpler logic works fine. Template recommendation didn't need a language model. Translation did. Knowing the difference matters for both product quality and your AWS bill.

The PDF Problem Nobody Warns You About

This is the part I wish someone had told me before I started.

Generating PDFs for English text using something like Puppeteer or a Lambda-based renderer is straightforward. You render HTML, you print to PDF, you're done.

Generating PDFs for Devanagari script (Hindi, Marathi) is a different problem entirely. And for Urdu (right-to-left, Nastaliq script) it's a problem on top of a problem.

The failure modes I hit:

Font subsetting issues — PDF generation libraries often subset fonts to reduce file size, which means they only embed the characters they think they need. For Latin alphabets this is fine. For Devanagari, which has hundreds of conjunct characters formed by combining base letters, the subsetting logic would often miss characters and you'd get rectangles instead of text.

Shaping not happening — Devanagari isn't just "different characters." Letters change shape depending on what's next to them. A "ka" followed by a vowel mark looks completely different from a standalone "ka." The rendering engine needs to understand this. Browser engines do. Some server-side PDF generators don't.

Line height chaos — Devanagari characters have vertical extenders that go above the line (matras). Many renderers didn't account for this properly, so lines of text would visually overlap.

The fix that actually worked: I moved to server-side rendering via Lambda using a headless Chromium build (via chrome-aws-lambda). Browser rendering engines handle complex scripts correctly because they've invested years in getting this right. Reusing that instead of trying to replicate it was the right call.

The tradeoff: cold start latency on Lambda went up noticeably with a full Chromium binary. I mitigated this with provisioned concurrency on the PDF generation function, which added cost but made the experience acceptable.

If I was starting over, I'd look at this constraint on day one rather than discovering it six weeks in.

Serverless: What Was Actually Good and What Was Annoying

I went all-in on serverless (Lambda + API Gateway + DynamoDB) for a few reasons that I think hold up in retrospect:

Good:

Zero infra management. I have no EC2 instances to patch, no RDS to babysit, no Nginx config to tweak.
The cost model is excellent at low-to-medium traffic. You pay for invocations, not uptime.
Lambda + S3 is a very natural fit for the PDF generation flow — generate, store, return a signed URL.
Deployment is simple enough that I can ship a fix in under five minutes.
Annoying:

Cold starts. Already mentioned this with the PDF function. For functions that run rarely, the first invocation has noticeable latency. Provisioned concurrency fixes it but costs money.
DynamoDB's access patterns require you to think about your queries upfront. Coming from a SQL background, the "you must know your access patterns before you design your schema" constraint is genuinely disorienting at first.
Local development is worse than with a traditional backend. There are tools (SAM, LocalStack) but they add friction. I ended up with a hybrid where I ran some things locally and tested others directly in a dev environment.
For a solo builder at early stage I'd make the same choice again. The operational simplicity is worth the tradeoffs.

PostHog Was More Useful Than I Expected

I added PostHog mostly because it was easy to add. It ended up being one of the more valuable tools in the stack.

The specific thing that helped: session recordings. Not for analytics dashboards — I barely look at those. But for watching real users hit confusing parts of the flow.

I found out my download button was in the wrong place by watching five consecutive session recordings of users who scrolled past it, looked confused, and left. I had never noticed this myself because I knew where the button was.

If you're building a product with non-technical users, session recording is worth the setup time. You will see things you'd never find through surveys or metrics alone.

What I'd Do Differently

Use a better PDF approach from the start. The multilingual rendering issue was foreseeable. I should have built a prototype specifically testing Hindi and Marathi rendering in week one, not week six.

Think harder about the data model before writing DynamoDB code. I refactored my access patterns twice. Both times were painful. Read the DynamoDB docs on single-table design before you write your first table, not after.

Smaller prompt, more testing. My translation prompt went through fifteen versions partially because I kept adding rules reactively when something broke. A more systematic approach to testing edge cases upfront would have gotten me to version 5 instead of version 15.

Earlier SEO. I left this for "later." Later turned out to mean month four. The compounding nature of organic search means every month you delay is a month of delayed growth. Should have done keyword research in week one alongside product research.

The translation feature is genuinely useful and I couldn't have built it as well without an LLM. The prompt engineering work was real work. Getting structured, reliable output from a model that handles cultural context correctly took time. I think it creates real value.

The template recommendation feature I talked about earlier — the one that's just scoring rules — probably gets labeled as "AI" in product copy. It isn't really. It's a lookup. I'm fine with this because it works and users don't care how it works, but I wanted to be honest here.

The stuff I chose not to build: I looked at AI-generated biodata content ("tell us about yourself and we'll write it") and decided against it. The biodata is a deeply personal document and families are suspicious of anything that feels inauthentic. Even if the output was good, I don't think users would trust it. That's a product judgment, not a technical one.

Anyway — the product is live at shadibiodata.com if you want to poke at it. Happy to answer questions about any of the technical bits in the comments. The Lambda + Chromium PDF setup in particular I could write a whole separate post about if there's interest.

The dev.to version leans into specifics — actual prompt structure, the reasoning behind technical choices, what didn't work before what did, honest assessment of what was actually "AI" versus marketing. That's what dev.to readers appreciate most.