Something you won’t see in the glossy brochures: 15 prompt iterations. That’s what it took for one developer to get a simple language translation right for marriage biodata, a task often touted as a no-brainer for modern AI.
My name is Maya, and I’ve been slogging through the tech trenches for two decades, watching shiny new toys get rolled out with the fanfare of a moon landing, only to end up gathering dust in a server closet. So when I saw this piece about wiring Claude AI into a SaaS product for Indian marriage biodata—shadibiodata.com, if you’re curious—I leaned in. Not for the usual Silicon Valley pixie dust, but for the grit. The actual, nitty-gritty of what worked and what was just… noise.
For the uninitiated (and let’s be honest, that’s most of us outside of specific cultural contexts), marriage biodata is essentially a resume for arranged marriages in India. Name, education, career, family lineage—the works. Culturally significant, yet historically, churned out on clunky Word documents.
This isn’t a puff piece about a new product. It’s about the trenches. The tech stack? Next.js and TypeScript fronted, AWS Lambda for backends, the whole DynamoDB/S3/CloudFront circus, Bedrock for the AI bits, and PostHog/Sentry for the vital task of knowing when things blow up.
The author is crystal clear from the jump: this wasn’t about slapping AI onto the product for the sake of it. It was about solving two concrete problems. Problem one: The sheer linguistic chaos of India. A family in Maharashtra needs Marathi. The online profile is English. The WhatsApp message to a potential suitor’s family in Nagpur? Hindi. One click, three languages. Ideally.
Problem two: The paralysis of choice. Ten templates, and users were drowning. Classic paradox of choice in action. They’d stare, click, retreat, and sometimes just bail. A nudge was needed, but not a full-blown interrogation.
These felt like AI’s bread and butter, right? Translate this, recommend that. The devil, as always, was in the details.
The Translation Tantrum
The naive approach is seductive: dump form data, ask LLM, voilà. Except the output was a dumpster fire. Names like ‘Priya Sharma’ translated into their literal Sanskrit meanings, dates reformatted into oblivion, degrees like ‘B.Tech Computer Science’ rendered into awkward Hindi descriptions instead of being left as is. And the truly cultural bits—‘Gotra,’ a Hindu clan identifier—got mangled into vague approximations. Fifteen prompt iterations, folks. Fifteen.
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.
This is where the real expertise shines through, not in the initial ‘can it do it?’ but the ‘can it do it correctly?’
Template Recommendation: Simpler is Smarter
Here’s a gem that cuts through the AI hype: The initial instinct was to go complex. Vector search, classifiers, maybe even a fine-tuned model. All the bells and whistles. Then, a moment of clarity. What data did the developer actually have?
Religion. Language preference. A single onboarding question about being ‘traditional’ or ‘modern’. Region (pulled from city input).
And what was needed? To trim ten templates down to two or three likely candidates. The solution? A rule-based scoring system. Templates tagged (traditional, modern, minimal, etc.), user profile mapped to a weighted vector, top scores win. No LLM. No API calls. Just a lookup.
This is a crucial distinction. There’s a siren song luring everyone towards LLMs, but sometimes, plain old logic—and a significantly smaller AWS bill—does the job. Template recommendation did not need a language model. Translation, however, absolutely did.
The PDF Printing Purgatory
Now for the real kicker, the part that could have sunk the entire operation: PDF generation. For English text, it’s child’s play. Puppeteer, Lambda renderers—easy peasy. But Devanagari script? That’s a whole different beast. And Urdu, with its right-to-left Nastaliq script? A nightmare stacked on a nightmare.
The issues piled up: font subsetting, where libraries embed only characters they think they need, leading to gaping rectangles where text should be. Shaping, where letters morph based on context—something browsers handle expertly, but some server-side tools punted on. And line height chaos, where vertical extenders from Devanagari characters crashed into each other.
The actual fix? Moving to server-side rendering via Lambda using a headless Chromium build. Because browser rendering engines have spent years perfecting complex script handling. Why reinvent the wheel when you can just reuse the perfectly good one that’s already spinning?
This entire process highlights a fundamental truth about AI integration: it’s rarely about the AI itself, but about its ability to solve a specific, well-defined problem that couldn’t be solved elegantly otherwise. And sometimes, the most elegant solution involves recognizing that the AI-shaped hole isn’t actually that big, or it’s already filled by something else.
This isn’t about bashing AI. It’s about wielding it with a surgeon’s precision, not a sledgehammer. The real win here isn’t just the functional biodata generator; it’s the hard-won wisdom about where to apply AI and where to keep it simple. And, let’s be honest, that’s a lesson worth far more than any buzzword.
AI in this context is a tool, and like any tool, its effectiveness hinges on understanding its limitations and strengths. Over-reliance or misapplication leads to bloat, cost overruns, and ultimately, a product that fails to deliver.
