DEV Community: Mohit

Building Minyut: An Embeddable RAG Chatbot in One Script Tag

Mohit — Thu, 18 Jun 2026 05:50:00 +0000

A client needed their customers to be able to query a 40-page policy document without reading through it.

We built the first version of what became Minyut in a weekend.

It used a basic embedding approach, answered from an OpenAI endpoint, and—in testing—confidently responded to questions that had no answer in the document at all.

It made things up.

Fluently.

Completely wrong.

That was the founding problem.

Every document chatbot we tested made things up. Not because the models were bad, but because they weren't constrained to answer only from the documents.

Minyut is built around a single architectural decision:

Every answer must come from uploaded content—or the chatbot says, "I don't know."

Everything else follows from that constraint.

Today, Minyut processes queries for chatbots embedded on Webflow sites, WordPress installs, Shopify stores, React apps, and plain HTML pages.

Documents are stored in Supabase's Mumbai region, and the widget can be embedded with a single script tag in under ten minutes.

Here's how it's built.

The Problem That Refused to Go Away: Knowledge Isolation

Standard AI chatbots answer from their training data.

For general knowledge, that's exactly what you want.

For support chatbots, legal documents, policy manuals, product specifications, and consultancy websites, accuracy becomes a liability issue rather than a convenience feature.

A chatbot that invents policy details isn't a support tool.

It's a liability.

The solution is Retrieval-Augmented Generation (RAG).

At query time:

The user's question becomes a vector embedding.
Relevant document chunks are retrieved.
Only those chunks are sent to the language model.
The model answers using the retrieved context.

If the answer isn't present in the uploaded documents, the chatbot says so.

The language model can only answer as well as the passages you retrieve.

Good retrieval is most of the battle.

The Chunking and Embedding Pipeline

Documents arrive as:

PDF
Markdown
Plain text

File limits:

Free plan: 5 MB
Paid plans: 25 MB

After extraction, documents are chunked.

Attempt 1: Sentence-Level Chunks

Each sentence became its own chunk.

Retrieval was precise but context disappeared.

Example:

Question: What is the refund window?

Retrieved:

Refunds are processed in 7 days.

Technically correct.

Practically useless.

Attempt 2: Full Paragraphs

Context improved.

Retrieval consistency did not.

Short and long paragraphs behaved very differently during similarity search.

Final Approach: Fixed Chunks With Overlap

Current strategy:

600-token chunks
80-token overlap

The overlap ensures sentences crossing chunk boundaries remain complete in at least one retrieved section.

For Minyut's document types, answer quality improved significantly.

Each chunk is embedded using:

sentence-transformers/all-MiniLM-L6-v2

via the HuggingFace Inference API.

The model generates:

384-dimensional vectors
Fast indexing
Strong semantic search performance

Vectors are stored in:

PostgreSQL
pgvector extension
HNSW index

inside Supabase.

The Widget: One Script Tag, No CSS Conflicts

The hard problem wasn't loading a script.

It was ensuring the widget worked everywhere.

Different host websites bring:

Different CSS frameworks
Different z-index rules
Different positioning systems

Our first approach used scoped CSS.

It failed repeatedly.

Examples:

WordPress themes overriding positioning
Global CSS affecting widget layout
Z-index conflicts hiding the chat button

The solution was Shadow DOM.

The widget creates a completely isolated DOM tree.

Host styles cannot leak in.

Widget styles cannot leak out.

const host = document.createElement('div');
document.body.appendChild(host);

const shadow = host.attachShadow({
  mode: 'open'
});

Everything lives inside the shadow root.

Style conflicts effectively disappear.

The widget is delivered as a single async script:

<script async src="https://minyut.com/widget.js"></script>

Advanced users can control behavior through:

window.__minyut__

including:

Opening the widget
Closing the widget
Prefilling messages
Listening to events

Infrastructure

Minyut's stack is intentionally simple.

Supabase

Handles:

PostgreSQL
Authentication
Storage
pgvector
Edge Functions

Netlify

Hosts:

Marketing website
Dashboard
Widget CDN

Razorpay

Handles subscription billing.

HuggingFace

Provides embedding generation.

Groq

Handles language model inference.

Storage Security

Documents are stored in:

Private buckets
Account-scoped access
No cross-account visibility

BYOK

Bring Your Own Key support allows users to connect:

Groq
OpenAI

Keys are encrypted using AES-256.

We never need to operate GPU infrastructure ourselves.

At Minyut's current scale, that's exactly the tradeoff we want.

The Pricing Decision: No Token Meters

The most common complaint about chatbot SaaS products isn't quality.

It's billing uncertainty.

Usage-based pricing creates anxiety.

A traffic spike should not become a surprise invoice.

Minyut uses fixed monthly plans.

Users receive notifications at:

80% usage
100% usage

Nothing fails silently.

Tinkerers (Free)

1 chatbot
3 documents
100 queries/month

Starter ($5/month)

3 chatbots
10 documents
500 queries/month

Pro ($12/month)

10 chatbots
Unlimited documents
2,000 queries/month
Custom domains
Analytics
Priority support

BYOK ($3/month)

Unlimited queries through the user's own OpenAI or Groq key.

We handle:

Storage
Dashboard
Bandwidth
Infrastructure

Users pay model providers directly.

Three Things That Would Have Saved Us Time

1. Chunking Matters More Than Models

We spent weeks comparing language models.

The bigger factor was chunk size and overlap.

Fix retrieval before optimizing inference.

2. Shadow DOM Solves Widget CSS Problems

Scoped CSS eventually breaks.

Shadow DOM doesn't.

Once we switched, CSS-related issues effectively disappeared.

3. Design for BYOK Early

The users who want BYOK are often the most engaged.

They build real systems.

Supporting them from the start avoids painful architectural changes later.

Conclusion

Minyut started as an attempt to solve a simple problem:

How do you build a chatbot that answers only from documents and refuses to invent information?

The answer ended up being a combination of:

Retrieval-Augmented Generation
Careful chunking
Semantic search
Shadow DOM isolation
A simple deployment model

The result is a chatbot that can be embedded on almost any website using a single script tag and answer only from uploaded content.

That's exactly what we set out to build.

Frequently Asked Questions

What file types does Minyut support?

PDF
Markdown (.md)
Plain text (.txt)

Will it answer questions not present in my documents?

No.

Minyut is designed specifically for document-grounded responses.

If the information isn't present in uploaded content, the chatbot says it doesn't know.

Which platforms does the embed support?

The widget has been tested on:

WordPress
Webflow
Shopify
Framer
React
Next.js
Plain HTML

Because it uses Shadow DOM isolation, it works reliably across virtually any platform that permits custom JavaScript.

How We Automated Purchase Orders From Gmail to Tally Using GPT-4 (98% Extraction Accuracy)

Mohit — Thu, 11 Jun 2026 12:30:00 +0000

At 9:14am on a Tuesday, the system flagged an incoming purchase order from a large enterprise buyer as a duplicate.

The PO had arrived in two separate emails over 48 hours — sent by different procurement contacts, both for the same batch of stainless steel flanges, same quantities, same delivery window.

Under the old system, a staff member would have read both, entered both into Tally, and allocated raw material stock twice. The first sign of the error would have been an inventory shortfall two weeks later.

The client is a Jaipur-based precision manufacturer serving enterprise buyers in India and overseas. At roughly ₹60Cr annual revenue, their team handled a steady flow of purchase orders across a demanding customer base.

Every one of those orders arrived as a PDF in a shared Gmail inbox.

Every one of those PDFs was read and entered into Tally by hand.

This is the build log for the system built to replace that process.

The Problem: PDFs in Gmail, Nobody Watching

The procurement workflow before the build:

Emails arrive in a shared Gmail inbox.
A staff member opens each attachment.
Reads part numbers, quantities, delivery deadlines, and supplier codes.
Manually enters everything into Tally.

On a slow day this took around 90 minutes.

On heavier order days, it could stretch to 3–4 hours.

The inbox had no workflow state:

No processed flag
No queue
No audit trail outside Tally

If the same PO arrived twice, the team would know only by accident.

Duplicate Orders

There was no detection mechanism.

Two contacts at the same enterprise customer could send the same PO independently, and neither Gmail nor Tally would flag it.

No Operational Visibility

Knowing which orders were due the following week required opening Tally and manually cross-referencing entries.

There was:

No dashboard
No queue view
No workload overview

Manual Raw Material Calculations

Once a PO was entered, another manual calculation followed:

Pulling specifications from the PDF
Checking stock levels
Estimating requirements

This introduced a second opportunity for human error.

What Was Built: A Four-Stage Pipeline

Each stage solved a different operational problem.

1. Gmail Push Notifications

Instead of polling Gmail every few minutes, the system registers a Google Cloud Pub/Sub topic that triggers a webhook whenever a new email arrives.

Benefits:

Near real-time processing
Lower infrastructure overhead
Faster visibility for operations teams

A PO is processed before a staff member would have opened the email.

2. GPT-4 Structured Extraction

The system sends the purchase order to GPT-4 using a strict JSON schema.

Required fields include:

PO number
Supplier details
Delivery date
Line items
Quantities

The model returns structured JSON directly.

No:

Regex maintenance
Template mapping
Field-position assumptions

For scanned PDFs, the vision endpoint is used.

For text PDFs, extracted text is sent directly.

Both paths produce the same JSON output.

3. Tally Integration

The extracted JSON is converted into a Tally-compatible XML purchase voucher and sent to Tally Prime's local HTTP server.

Once accepted:

The voucher is created automatically.
Inventory calculations run immediately.
The order appears exactly as if a user entered it manually.

4. Duplicate Detection

Every incoming PO is stored in PostgreSQL.

A normalized fingerprint is generated using:

Line items
Quantities
Delivery windows

This allows the system to detect duplicate orders before they reach Tally.

The duplicate mentioned earlier was caught using this mechanism.

The Technology Stack

Backend

FastAPI
PostgreSQL
Gmail API
Google Pub/Sub

Frontend

React
Framer Motion

AI Layer

GPT-4 Structured Outputs
GPT-4 Vision

ERP Layer

Tally Prime via TDL XML imports

Working with the Tally API

The official documentation leaves a lot to be desired.

The most reliable approach is:

Enable Tally's HTTP server.
Generate TDL XML vouchers.
POST them to Tally.
Parse the acknowledgement response.

Enable Tally HTTP Server

Gateway of Tally
→ F12
→ Advanced Configuration
→ Enable ODBC/HTTP Server

Minimal Purchase Voucher Example

<ENVELOPE>
  <HEADER>
    <TALLYREQUEST>Import Data</TALLYREQUEST>
  </HEADER>
  <BODY>
    <IMPORTDATA>
      <REQUESTDESC>
        <REPORTNAME>Vouchers</REPORTNAME>
        <STATICVARIABLES>
          <SVCURRENTCOMPANY>[Company Name]</SVCURRENTCOMPANY>
        </STATICVARIABLES>
      </REQUESTDESC>
      <REQUESTDATA>
        <TALLYMESSAGE xmlns:UDF="TallyUDF">
          <VOUCHER VCHTYPE="Purchase" ACTION="Create">
            <DATE>[YYYYMMDD]</DATE>
            <VOUCHERTYPENAME>Purchase</VOUCHERTYPENAME>
            <PARTYLEDGERNAME>[Supplier Name]</PARTYLEDGERNAME>
            <ALLLEDGERENTRIES.LIST>
              <LEDGERNAME>[Ledger]</LEDGERNAME>
              <AMOUNT>[Amount]</AMOUNT>
            </ALLLEDGERENTRIES.LIST>
          </VOUCHER>
        </TALLYMESSAGE>
      </REQUESTDATA>
    </IMPORTDATA>
  </BODY>
</ENVELOPE>

The first working voucher took three days.

Everything after that was extension work.

The Admin Dashboard

The dashboard became the team's primary operational interface.

Orders Panel

Shows:

Status
Supplier
PO Number
Delivery Deadline
Part Count

Duplicate orders are highlighted and blocked from entering Tally until reviewed.

Tally Panel

Provides:

Revenue trends
Receivables
Payment status

Without opening Tally.

Operations Panel

Handles:

Dispatch notes
QA checklists
Production milestones

All driven from the same purchase-order data.

What Failed First

The original extraction system used:

pdf-parse
OCR
Regex pipelines

The assumption:

Purchase order formats would remain stable.

They didn't.

Enterprise customers used:

Multiple templates
Different table structures
Scanned PDFs
International formats

The result:

~60% success rate
Frequent maintenance
Silent extraction failures

One part-number transposition eventually led to production of an incorrect batch.

That was the turning point.

The system was rebuilt around GPT-4 structured outputs.

Validation against historical purchase orders increased extraction accuracy from roughly 60% to over 98%.

Three Lessons From the Project

1. PDF Extraction Has a Clear ROI

For teams processing purchase orders every week:

AI costs remain small.
Manual labor costs do not.

The business case becomes obvious once the numbers are compared.

2. Tally Integration Is Easier Than Its Reputation

The difficult part is finding a working example.

Once you successfully create one XML voucher, the rest is straightforward engineering.

3. Push Beats Polling

The biggest benefit wasn't lower latency.

It was trust.

A dashboard updated within seconds becomes an operational tool.

A dashboard updated every few minutes becomes a report.

That difference determines whether teams actually adopt the system.

Could This Work For Your Business?

If your team receives PDFs in Gmail and manually enters them into:

Tally
ERP systems
Inventory software

the workflow can likely be automated.

The core pattern is repeatable:

Gmail
→ AI Extraction
→ Validation
→ ERP Integration
→ Operations Dashboard

This project went from discovery call to production deployment in six weeks.

FAQ

Does this work with Tally ERP 9?

Yes.

The XML import approach works with both:

Tally Prime
Tally ERP 9

The main requirement is enabling Tally's HTTP server.

Can it process scanned PDFs?

Yes.

Scanned PDFs use GPT-4 Vision.

Text PDFs use direct extraction.

Both produce the same structured output.

What if the AI extracts incorrect data?

The system includes:

Confidence scoring
Validation rules
Human review queues

Suspicious records are blocked before reaching Tally.

This prevents errors from entering downstream operations.