How ShadiBiodata.com Uses AI to Rebuild the Indian Marriage Biodata: A Technical Overview

For most of the last three decades, the Indian marriage biodata has lived inside Microsoft Word. One page, a passport photo pasted into the top-right corner, and a table of fields that somebody’s uncle formatted in 2009 and the family has been copy-pasting ever since. It works the way a fax machine works.

The document carries more weight than the tooling suggests. It’s the first thing a prospective family sees, it circulates through WhatsApp groups and marriage bureaus, and it gets judged in about seven seconds. The software available to produce it has mostly been generic design tools that know nothing about what a biodata actually is.

[ShadiBiodata.com](https://shadibiodata.com/) goes the other way. It’s a purpose-built document generator for one narrow category of document, and it hands language models the parts that are genuinely hard: reading a scanned biodata from 2014, cleaning up fields people typed in a hurry, and pushing Indian names and place names into eleven regional scripts without mangling them. Here’s how that stack is put together.

## The problem nobody solved: data entry

Ask anyone who’s made a biodata what took longest and the answer is never “choosing a design.” It’s typing the same twenty-five fields for the third time.

Most families already have a biodata somewhere. A PDF a cousin made. A photo of a printed sheet. A .doc file that’s survived four laptops. Re-keying all of it into a new tool is where people quit.

ShadiBiodata handles this with document extraction running on Amazon Bedrock. Upload a PDF, a JPEG, a Word file, even an Excel sheet, anything up to 15MB, and an Amazon Nova Lite model reads it against a field map of the app’s own form schema. The model gets told which fields exist and what each one means, then matches what it finds in the document against them, creating new fields for anything that doesn’t fit the standard set.

Two decisions there are worth pulling out.

The first is that every extracted value carries a confidence rating. Handwriting that was unclear, a photocopy with a smudge, a match the model was frankly guessing at: those come back flagged low-confidence, and the app puts them in front of the user to check instead of quietly accepting them. A biodata with a wrong date of birth is worse than no biodata.

The second is that extracted values stay exactly as the source document wrote them. The form’s dropdowns are comboboxes that accept free text, so if the original said “Wheatish (fair side)” it stays that way rather than being forced onto the nearest preset. Religion is the one exception and does get normalised to a code, because several downstream behaviours depend on reading it reliably, including which astrological fields appear and which templates get recommended.

## Cleanup without invention

The second AI feature changes how the finished document reads. ShadiBiodata calls it “Regenerate with AI,” and what it does is take everything a user typed and tidy it up.

Real biodata data is messy in predictable ways. Labels arrive as `MOTHERS’s NAME`. Values arrive as `10th, 12th, B.Tech – XYZ College Pune` crammed into a single Education field. Capitalisation wanders, spacing is erratic, phrasing drifts between formal and casual depending on which family member was dictating.

The service sends the form data to a Claude model on Bedrock, Sonnet as the primary with Haiku as a fallback when Sonnet is slow or overloaded. The system prompt is mostly a list of things the model isn’t allowed to do:

– Never invent facts. It may clean up what’s there. It may not add, exaggerate, or embellish, and a detail can only be dropped when it’s genuinely redundant.

– Never translate. Whatever script a field was written in, Devanagari or Gujarati or Latin, the output stays in that script. Simplify within the language, don’t switch languages.

– Never get literary. The instruction is explicit that plain wording must not be rewritten into formal or ornate English. Biodatas get read by people of every education level.

– Never touch certain fields. Date of birth, time of birth and height are locked completely. Full name has its label locked, so only obvious typos in the value get corrected.

That last rule exists because those are the fields where a confident model mistake does the most damage. Time of birth feeds astrological calculation. A “corrected” one produces a wrong nakshatra, and nobody catches it until a pandit does.

The model gets permission for exactly one structural change: splitting a bundled value across multiple fields. The Education example above becomes “School Education” and “Graduation” as separate rows, each with its own specific label. The prompt is unusually insistent that split labels be distinct and human-readable, never a code-like string such as `fields.nativePlace`, and never the same generic label twice.

## Showing the user what changed

Handing someone an AI-rewritten version of their own personal details without showing them what moved is a trust problem, not a technical one.

ShadiBiodata computes a diff on the client between what the user typed and what the model returned, then puts it behind an “N changes” chip next to the AI toggle. Opening it lists every edit grouped by section, before and after, marked as a label edit, a value edit, both, or a newly split-out field.

Small feature. It’s also the difference between someone trusting the output enough to send it to a prospective family and someone switching the whole thing off.

## Eleven languages, and why translation is harder than it looks

The app runs in twelve languages: English plus Hindi, Marathi, Gujarati, Bengali, Tamil, Telugu, Kannada, Malayalam, Odia, Punjabi and Urdu. Translating a biodata isn’t the same problem as translating a webpage, and the translation service treats it as its own thing.

What the system enforces is the line between transliteration and translation, field by field:

| Content type | Treatment | Example |

|—|—|—|

| Person names | Transliterate | Anjali Sharma to अंजली शर्मा |

| Cities, villages, districts | Transliterate | Nashik to नाशिक |

| Colleges, employers | Transliterate | Infosys to इन्फोसिस |

| Degree abbreviations | Transliterate | B.Tech to बी.टेक |

| Job titles and occupations | Translate idiomatically | Software Engineer to सॉफ्टवेअर अभियंता |

| Field labels | Translate naturally | Father’s Name to वडिलांचे नाव |

Get this backwards and the output is unusable. A translated surname is nonsense. A transliterated job title reads like a machine wrote it. The prompt encodes the cultural categories a general-purpose translation API has no concept of, gotra and nakshatra and rashi and nadi among them, and results are cached in DynamoDB so repeat translations of common values cost nothing.

There’s also a per-field suggestion mode. Typing in a non-English language, a user can ask for alternative phrasings of a single field, and the service tracks what it has already shown so that asking again returns genuinely new options instead of the same three.

## Astrology as a calculated field, not a text box

Hindu biodatas are expected to carry six astrological fields, rashi and nakshatra and nadi and gan and manglik status among them. Most tools present these as empty text boxes and leave the family to go find a pandit or another app.

ShadiBiodata computes them. Enter a date of birth and a time of birth and the astrology service returns all five values, which the app then offers to auto-fill after the user confirms. Time of birth is optional; when it’s missing the calculation defaults to noon, which is the standard convention anyway.

A separate classification model reads name, gotra and caste to infer religion, which feeds template recommendation. A Muslim biodata shouldn’t open on a template built around Ganesha motifs. The classifier is deliberately conservative and returns “Unknown” rather than guessing, which for this particular inference is the right way to fail.

## The rendering pipeline

Sixty-one templates ship with the app. The rendering side carries a surprising amount of engineering, because the constraint is unforgiving: an Indian marriage biodata is expected to be exactly one page.

PDFs come out of headless Chromium running in AWS Lambda. Every template declares A4 dimensions, and the generator measures rendered output against the sheet that actually gets printed, 793.92 by 1123.2 CSS pixels, with under a pixel of slack. When content overflows, a fit-to-page pass scales fonts and spacing down until it fits, with a floor of 0.55x so text never becomes unreadable. When content under-fills the page, the same pass scales up. A compact two-column layout handles biodatas with unusually many fields. Finished PDFs go out through CloudFront with signed URLs.

On the input side, the [marriage biodata maker](https://shadibiodata.com/marriage-biodata-maker/) renders a live template preview beside the form on desktop, updating as fields are typed, with sample data filling the gaps so the page never looks broken mid-entry. Fields can be dragged into a different order, renamed, or added outright.

One architectural choice deserves a mention. Biodata data lives in the browser, not on a server. For a document holding a woman’s date of birth, photograph, home city and phone number, that’s a meaningful decision. There’s no database to breach because there’s no database.

## What this says about vertical software

Every product uses language models now, so that isn’t what makes ShadiBiodata interesting.

What makes it interesting is that every model call is narrow and wrapped in rules derived from the specific document being produced. The cleanup model can’t invent a job title. The extraction model has to admit when it couldn’t read something. The translation model knows a gotra gets transliterated and an occupation gets translated. The religion classifier would rather say “Unknown” than be wrong.

That’s the opposite of the general-purpose assistant pattern, and for documents that carry real social weight it’s the pattern that holds up. A chatbot that can write anything has no particular advantage over a system that can only write biodatas and has been told, in detail, what a good one looks like.

Pricing sits where it needs to for the Indian market. Templates run ₹19 to ₹88, there’s a free option, and payment opens a thirty-minute window for edits and re-downloads. But the pricing is downstream of the real point, which is that a category of document nobody was building software for turned out to have enough depth to justify building software for it.

Ready to Use HTML

<title>The Biodata Stack</title>

<link rel=”preconnect” href=”https://fonts.googleapis.com”>

<link rel=”preconnect” href=”https://fonts.gstatic.com” crossorigin>

<link rel=”stylesheet” href=”https://fonts.googleapis.com/css2?family=Fraunces:opsz,[email protected],500;9..144,600&family=IBM+Plex+Sans:wght@400;500;600&family=IBM+Plex+Mono:wght@400;500&family=Noto+Sans+Devanagari:wght@400;500&display=swap”>

<style>

 :root {

   –paper:      #FBFAF8;

   –surface:    #FFFFFF;

   –ink:        #17181C;

   –ink-muted:  #5C5A57;

   –ink-faint:  #8A8681;

   –rule:       #E4E2DC;

   –rule-soft:  #EFEDE8;

   –accent:     #B4271F;

   –accent-bg:  #F7EBE9;

   –gold:       #8C6A21;

   –focus:      #B4271F;

   –serif: ‘Fraunces’, ‘Iowan Old Style’, Georgia, ‘Times New Roman’, serif;

   –sans:  ‘IBM Plex Sans’, ‘Noto Sans Devanagari’, system-ui, -apple-system, ‘Segoe UI’, sans-serif;

   –mono:  ‘IBM Plex Mono’, ui-monospace, ‘SF Mono’, Menlo, Consolas, monospace;

   –deva:  ‘Noto Sans Devanagari’, ‘IBM Plex Sans’, system-ui, sans-serif;

   –measure: 66ch;

 }

 @media (prefers-color-scheme: dark) {

   :root:not([data-theme=”light”]) {

     –paper:      #191614;

     –surface:    #211D1B;

     –ink:        #EDE9E4;

     –ink-muted:  #A8A099;

     –ink-faint:  #7C746D;

     –rule:       #363029;

     –rule-soft:  #2A2522;

     –accent:     #E86A5E;

     –accent-bg:  #2E201E;

     –gold:       #C9A24D;

     –focus:      #E86A5E;

   }

 }

 :root[data-theme=”dark”] {

   –paper:      #191614;

   –surface:    #211D1B;

   –ink:        #EDE9E4;

   –ink-muted:  #A8A099;

   –ink-faint:  #7C746D;

   –rule:       #363029;

   –rule-soft:  #2A2522;

   –accent:     #E86A5E;

   –accent-bg:  #2E201E;

   –gold:       #C9A24D;

   –focus:      #E86A5E;

 }

 body {

   background: var(–paper);

   color: var(–ink);

   font-family: var(–sans);

   font-size: 17px;

   line-height: 1.72;

   -webkit-font-smoothing: antialiased;

 }

 .wrap {

   max-width: var(–measure);

   margin: 0 auto;

   padding: clamp(2.5rem, 1.5rem + 4vw, 5.5rem) clamp(1.25rem, 0.5rem + 3vw, 2rem) 5rem;

   display: flex;

   flex-direction: column;

   gap: 1.5rem;

 }

 /* —- masthead —- */

 .eyebrow {

   font-family: var(–mono);

   font-size: 0.72rem;

   font-weight: 500;

   letter-spacing: 0.16em;

   text-transform: uppercase;

   color: var(–accent);

   display: flex;

   align-items: center;

   gap: 0.7rem;

 }

 .eyebrow::after {

   content: “”;

   flex: 1;

   height: 1px;

   background: var(–rule);

 }

 h1 {

   font-family: var(–serif);

   font-weight: 600;

   font-size: clamp(2rem, 1.3rem + 2.9vw, 3.15rem);

   line-height: 1.08;

   letter-spacing: -0.021em;

   text-wrap: balance;

   margin: 0;

 }

 .deck {

   font-family: var(–serif);

   font-weight: 500;

   font-size: clamp(1.05rem, 0.98rem + 0.4vw, 1.25rem);

   line-height: 1.5;

   color: var(–ink-muted);

   text-wrap: pretty;

   margin: 0;

 }

 /* —- biodata-style meta block —- */

 .meta {

   border-top: 2px solid var(–ink);

   border-bottom: 1px solid var(–rule);

   margin-top: 0.75rem;

 }

 .meta dl {

   margin: 0;

   display: grid;

   grid-template-columns: minmax(6.5rem, 9rem) 1fr;

 }

 .meta dt,

 .meta dd {

   margin: 0;

   padding: 0.55rem 0;

   border-bottom: 1px solid var(–rule-soft);

   font-size: 0.855rem;

 }

 .meta dl > :nth-last-child(-n+2) {

   border-bottom: 0;

 }

 .meta dt {

   font-family: var(–mono);

   font-size: 0.72rem;

   letter-spacing: 0.09em;

   text-transform: uppercase;

   color: var(–ink-faint);

   padding-top: 0.72rem;

 }

 .meta dd {

   color: var(–ink);

   font-weight: 500;

 }

 /* —- body copy —- */

 h2 {

   font-family: var(–serif);

   font-weight: 600;

   font-size: clamp(1.32rem, 1.15rem + 0.8vw, 1.72rem);

   line-height: 1.22;

   letter-spacing: -0.012em;

   text-wrap: balance;

   margin: 2.4rem 0 0;

   padding-top: 1.6rem;

   border-top: 1px solid var(–rule);

 }

 p {

   margin: 0;

   text-wrap: pretty;

 }

 .lede::first-letter {

   font-family: var(–serif);

   font-weight: 600;

   float: left;

   font-size: 3.5em;

   line-height: 0.82;

   padding: 0.07em 0.09em 0 0;

   color: var(–accent);

 }

 a {

   color: var(–accent);

   text-decoration-thickness: 1px;

   text-underline-offset: 0.18em;

   text-decoration-color: color-mix(in srgb, var(–accent) 45%, transparent);

 }

 a:hover {

   text-decoration-color: var(–accent);

 }

 a:focus-visible {

   outline: 2px solid var(–focus);

   outline-offset: 3px;

   border-radius: 2px;

 }

 code {

   font-family: var(–mono);

   font-size: 0.855em;

   background: var(–accent-bg);

   color: var(–ink);

   padding: 0.12em 0.36em;

   border-radius: 3px;

   word-break: break-word;

 }

 /* —- constraint list: a ruled rail, not cards —- */

 .rules {

   list-style: none;

   margin: 0.4rem 0 0;

   padding: 0 0 0 1.4rem;

   border-left: 2px solid var(–gold);

   display: flex;

   flex-direction: column;

   gap: 1rem;

 }

 .rules li {

   margin: 0;

 }

 .rules b {

   font-weight: 600;

   font-family: var(–serif);

   font-size: 1.06em;

 }

 /* —- transliteration table —- */

 .table-scroll {

   overflow-x: auto;

   margin: 0.4rem 0 0;

 }

 table {

   border-collapse: collapse;

   width: 100%;

   min-width: 34rem;

   font-size: 0.895rem;

 }

 thead th {

   font-family: var(–mono);

   font-size: 0.7rem;

   font-weight: 500;

   letter-spacing: 0.1em;

   text-transform: uppercase;

   color: var(–ink-faint);

   text-align: left;

   padding: 0 0.9rem 0.55rem 0;

   border-bottom: 2px solid var(–ink);

 }

 tbody td {

   padding: 0.62rem 0.9rem 0.62rem 0;

   border-bottom: 1px solid var(–rule-soft);

   vertical-align: top;

 }

 tbody tr:last-child td {

   border-bottom: 0;

 }

 tbody td:nth-child(2) {

   color: var(–ink-muted);

   white-space: nowrap;

 }

 tbody td:last-child {

   font-family: var(–deva);

   padding-right: 0;

 }

 /* —- closing note —- */

 .endmark {

   margin-top: 0.6rem;

   padding-top: 1.4rem;

   border-top: 1px solid var(–rule);

   font-family: var(–mono);

   font-size: 0.72rem;

   letter-spacing: 0.14em;

   text-transform: uppercase;

   color: var(–ink-faint);

 }

 @media (max-width: 34rem) {

   body { font-size: 16.5px; }

   .meta dl { grid-template-columns: 1fr; }

   .meta dt { padding-bottom: 0; border-bottom: 0; }

   .meta dd { padding-top: 0.15rem; }

 }

</style>

<article class=”wrap”>

 <p class=”eyebrow”>Software</p>

 <h1>How ShadiBiodata.com Uses AI to Rebuild the Indian Marriage Biodata</h1>

 <p class=”deck”>A purpose-built document generator for one narrow category of document, and what it hands to language models.</p>

 <div class=”meta”>

   <dl>

     <dt>Category</dt>

     <dd>Software &middot; Technical overview</dd>

     <dt>Subject</dt>

     <dd>ShadiBiodata.com</dd>

     <dt>Focus</dt>

     <dd>AI document generation, Amazon Bedrock</dd>

     <dt>Length</dt>

     <dd>1,742 words &middot; about 8 minutes</dd>

   </dl>

 </div>

 <p class=”lede”>For most of the last three decades, the Indian marriage biodata has lived inside Microsoft Word. One page, a passport photo pasted into the top-right corner, and a table of fields that somebody’s uncle formatted in 2009 and the family has been copy-pasting ever since. It works the way a fax machine works.</p>

 <p>The document carries more weight than the tooling suggests. It’s the first thing a prospective family sees, it circulates through WhatsApp groups and marriage bureaus, and it gets judged in about seven seconds. The software available to produce it has mostly been generic design tools that know nothing about what a biodata actually is.</p>

 <p><a href=”https://shadibiodata.com/”>ShadiBiodata.com</a> goes the other way. It’s a purpose-built document generator for one narrow category of document, and it hands language models the parts that are genuinely hard: reading a scanned biodata from 2014, cleaning up fields people typed in a hurry, and pushing Indian names and place names into eleven regional scripts without mangling them. Here’s how that stack is put together.</p>

 <h2>The problem nobody solved: data entry</h2>

 <p>Ask anyone who’s made a biodata what took longest and the answer is never “choosing a design.” It’s typing the same twenty-five fields for the third time.</p>

 <p>Most families already have a biodata somewhere. A PDF a cousin made. A photo of a printed sheet. A .doc file that’s survived four laptops. Re-keying all of it into a new tool is where people quit.</p>

 <p>ShadiBiodata handles this with document extraction running on Amazon Bedrock. Upload a PDF, a JPEG, a Word file, even an Excel sheet, anything up to 15MB, and an Amazon Nova Lite model reads it against a field map of the app’s own form schema. The model gets told which fields exist and what each one means, then matches what it finds in the document against them, creating new fields for anything that doesn’t fit the standard set.</p>

 <p>Two decisions there are worth pulling out.</p>

 <p>The first is that every extracted value carries a confidence rating. Handwriting that was unclear, a photocopy with a smudge, a match the model was frankly guessing at: those come back flagged low-confidence, and the app puts them in front of the user to check instead of quietly accepting them. A biodata with a wrong date of birth is worse than no biodata.</p>

 <p>The second is that extracted values stay exactly as the source document wrote them. The form’s dropdowns are comboboxes that accept free text, so if the original said “Wheatish (fair side)” it stays that way rather than being forced onto the nearest preset. Religion is the one exception and does get normalised to a code, because several downstream behaviours depend on reading it reliably, including which astrological fields appear and which templates get recommended.</p>

 <h2>Cleanup without invention</h2>

 <p>The second AI feature changes how the finished document reads. ShadiBiodata calls it “Regenerate with AI,” and what it does is take everything a user typed and tidy it up.</p>

 <p>Real biodata data is messy in predictable ways. Labels arrive as <code>MOTHERS’s NAME</code>. Values arrive as <code>10th, 12th, B.Tech – XYZ College Pune</code> crammed into a single Education field. Capitalisation wanders, spacing is erratic, phrasing drifts between formal and casual depending on which family member was dictating.</p>

 <p>The service sends the form data to a Claude model on Bedrock, Sonnet as the primary with Haiku as a fallback when Sonnet is slow or overloaded. The system prompt is mostly a list of things the model isn’t allowed to do:</p>

 <ul class=”rules”>

   <li><b>Never invent facts.</b> It may clean up what’s there. It may not add, exaggerate, or embellish, and a detail can only be dropped when it’s genuinely redundant.</li>

   <li><b>Never translate.</b> Whatever script a field was written in, Devanagari or Gujarati or Latin, the output stays in that script. Simplify within the language, don’t switch languages.</li>

   <li><b>Never get literary.</b> The instruction is explicit that plain wording must not be rewritten into formal or ornate English. Biodatas get read by people of every education level.</li>

   <li><b>Never touch certain fields.</b> Date of birth, time of birth and height are locked completely. Full name has its label locked, so only obvious typos in the value get corrected.</li>

 </ul>

 <p>That last rule exists because those are the fields where a confident model mistake does the most damage. Time of birth feeds astrological calculation. A “corrected” one produces a wrong nakshatra, and nobody catches it until a pandit does.</p>

 <p>The model gets permission for exactly one structural change: splitting a bundled value across multiple fields. The Education example above becomes “School Education” and “Graduation” as separate rows, each with its own specific label. The prompt is unusually insistent that split labels be distinct and human-readable, never a code-like string such as <code>fields.nativePlace</code>, and never the same generic label twice.</p>

 <h2>Showing the user what changed</h2>

 <p>Handing someone an AI-rewritten version of their own personal details without showing them what moved is a trust problem, not a technical one.</p>

 <p>ShadiBiodata computes a diff on the client between what the user typed and what the model returned, then puts it behind an “N changes” chip next to the AI toggle. Opening it lists every edit grouped by section, before and after, marked as a label edit, a value edit, both, or a newly split-out field.</p>

 <p>Small feature. It’s also the difference between someone trusting the output enough to send it to a prospective family and someone switching the whole thing off.</p>

 <h2>Eleven languages, and why translation is harder than it looks</h2>

 <p>The app runs in twelve languages: English plus Hindi, Marathi, Gujarati, Bengali, Tamil, Telugu, Kannada, Malayalam, Odia, Punjabi and Urdu. Translating a biodata isn’t the same problem as translating a webpage, and the translation service treats it as its own thing.</p>

 <p>What the system enforces is the line between transliteration and translation, field by field:</p>

 <div class=”table-scroll”>

   <table>

     <thead>

       <tr>

         <th scope=”col”>Content type</th>

         <th scope=”col”>Treatment</th>

         <th scope=”col”>Example</th>

       </tr>

     </thead>

     <tbody>

       <tr>

         <td>Person names</td>

         <td>Transliterate</td>

         <td>Anjali Sharma &rarr; अंजली शर्मा</td>

       </tr>

       <tr>

         <td>Cities, villages, districts</td>

         <td>Transliterate</td>

         <td>Nashik &rarr; नाशिक</td>

       </tr>

       <tr>

         <td>Colleges, employers</td>

         <td>Transliterate</td>

         <td>Infosys &rarr; इन्फोसिस</td>

       </tr>

       <tr>

         <td>Degree abbreviations</td>

         <td>Transliterate</td>

         <td>B.Tech &rarr; बी.टेक</td>

       </tr>

       <tr>

         <td>Job titles and occupations</td>

         <td>Translate idiomatically</td>

         <td>Software Engineer &rarr; सॉफ्टवेअर अभियंता</td>

       </tr>

       <tr>

         <td>Field labels</td>

         <td>Translate naturally</td>

         <td>Father’s Name &rarr; वडिलांचे नाव</td>

       </tr>

     </tbody>

   </table>

 </div>

 <p>Get this backwards and the output is unusable. A translated surname is nonsense. A transliterated job title reads like a machine wrote it. The prompt encodes the cultural categories a general-purpose translation API has no concept of, gotra and nakshatra and rashi and nadi among them, and results are cached in DynamoDB so repeat translations of common values cost nothing.</p>

 <p>There’s also a per-field suggestion mode. Typing in a non-English language, a user can ask for alternative phrasings of a single field, and the service tracks what it has already shown so that asking again returns genuinely new options instead of the same three.</p>

 <h2>Astrology as a calculated field, not a text box</h2>

 <p>Hindu biodatas are expected to carry six astrological fields, rashi and nakshatra and nadi and gan and manglik status among them. Most tools present these as empty text boxes and leave the family to go find a pandit or another app.</p>

 <p>ShadiBiodata computes them. Enter a date of birth and a time of birth and the astrology service returns all five values, which the app then offers to auto-fill after the user confirms. Time of birth is optional; when it’s missing the calculation defaults to noon, which is the standard convention anyway.</p>

 <p>A separate classification model reads name, gotra and caste to infer religion, which feeds template recommendation. A Muslim biodata shouldn’t open on a template built around Ganesha motifs. The classifier is deliberately conservative and returns “Unknown” rather than guessing, which for this particular inference is the right way to fail.</p>

 <h2>The rendering pipeline</h2>

 <p>Sixty-one templates ship with the app. The rendering side carries a surprising amount of engineering, because the constraint is unforgiving: an Indian marriage biodata is expected to be exactly one page.</p>

 <p>PDFs come out of headless Chromium running in AWS Lambda. Every template declares A4 dimensions, and the generator measures rendered output against the sheet that actually gets printed, 793.92 by 1123.2 CSS pixels, with under a pixel of slack. When content overflows, a fit-to-page pass scales fonts and spacing down until it fits, with a floor of 0.55x so text never becomes unreadable. When content under-fills the page, the same pass scales up. A compact two-column layout handles biodatas with unusually many fields. Finished PDFs go out through CloudFront with signed URLs.</p>

 <p>On the input side, the <a href=”https://shadibiodata.com/marriage-biodata-maker/”>marriage biodata maker</a> renders a live template preview beside the form on desktop, updating as fields are typed, with sample data filling the gaps so the page never looks broken mid-entry. Fields can be dragged into a different order, renamed, or added outright.</p>

 <p>One architectural choice deserves a mention. Biodata data lives in the browser, not on a server. For a document holding a woman’s date of birth, photograph, home city and phone number, that’s a meaningful decision. There’s no database to breach because there’s no database.</p>

 <h2>What this says about vertical software</h2>

 <p>Every product uses language models now, so that isn’t what makes ShadiBiodata interesting.</p>

 <p>What makes it interesting is that every model call is narrow and wrapped in rules derived from the specific document being produced. The cleanup model can’t invent a job title. The extraction model has to admit when it couldn’t read something. The translation model knows a gotra gets transliterated and an occupation gets translated. The religion classifier would rather say “Unknown” than be wrong.</p>

 <p>That’s the opposite of the general-purpose assistant pattern, and for documents that carry real social weight it’s the pattern that holds up. A chatbot that can write anything has no particular advantage over a system that can only write biodatas and has been told, in detail, what a good one looks like.</p>

 <p>Pricing sits where it needs to for the Indian market. Templates run &#8377;19 to &#8377;88, there’s a free option, and payment opens a thirty-minute window for edits and re-downloads. But the pricing is downstream of the real point, which is that a category of document nobody was building software for turned out to have enough depth to justify building software for it.</p>

 <p class=”endmark”>End of article</p>

</article>