DEV Community: Ujjawal Tyagi

Building LLMs for Bharat: What 6 Months of Rural AI Deployment Taught Us

Ujjawal Tyagi — Fri, 24 Apr 2026 10:55:37 +0000

Most coverage of "AI for India" treats the subject the way Silicon Valley treats emerging markets — translate the product, localize the UI, and you're done. Six months of production deployment of 7S Samiti, our AI tutor for rural Indian students, has taught us that this framing is almost completely wrong.

This is a piece about what we actually learned building an LLM-powered education product for students in low-connectivity, low-literacy-adjacent environments in rural India. It's not a case study about an AI that worked. It's a case study about the specific, surprising ways it broke, and what we did about it.

The Problem We Were Solving

7S Samiti is a mission-driven edtech platform. The goal: deliver personalized, adaptive learning to rural Indian students at a price point that doesn't exclude them. The stack:

Mobile app (Flutter, offline-first) deployed to entry-level Android phones.
AI tutor that generates quizzes, assignments, and study notes on demand, in the student's preferred language.
Local caching + selective sync for areas with 2G-only connectivity.
Parent/teacher dashboard for progress tracking.

We deployed to pilot schools in three states (Uttar Pradesh, Maharashtra, Rajasthan). 2,400 students in the initial rollout.

Failure #1: The Tokenization Problem

Every multilingual LLM paper talks about "parameter efficiency across languages." What they don't talk about: Hindi and Marathi have 2-4x worse tokenization efficiency than English in most off-the-shelf models.

A 200-word Hindi paragraph eats ~600 tokens where the English equivalent eats ~150. Latency is higher. Cost is higher. Quality of generation is often lower because you're burning context budget on writing the same content.

Three fixes that worked:

1. Route by language. English queries to GPT-4. Hindi/Marathi queries through a dedicated pathway with tokenizer-aware prompts.

2. Translate-generate-translate for complex content. For long-form study notes, we generate in English and translate to Hindi/Marathi as a post-process. Three model calls instead of one. Surprisingly produces higher-quality Hindi than direct generation, because the model's reasoning in English is stronger.

3. Pre-generate common content. 80% of what students request is predictable. We batch-generate overnight, cache it, and serve from cache for 90% of requests.

Result: latency dropped from ~4s to ~800ms for cached content. API cost dropped by 70%.

Failure #2: Voice vs. Text

Our initial app was text-first. Deployment showed us: rural Indian students use voice input 8x more often than text.

Many students are the first generation in their family learning to read and write fluently in their regional language. Typing in Devanagari or Marathi script on a tiny phone keyboard is slow and intimidating. Speaking is natural.

What we did:

Voice input became the default UX. App usage doubled within two weeks.
Audio output for all AI responses. Students listen 3x longer than they read.
Multimodal interaction for math. Students photo a math problem, we OCR + solve + explain by voice. Drove 40% of daily active usage in month one.

Failure #3: Connectivity Reality

We designed for "low bandwidth." Reality: students use the app during a 15-minute window when they have signal, then go offline for hours.

The naive implementation — real-time cloud LLM calls — doesn't work. Students tap "solve," wait 8 seconds, then lose signal mid-request.

What we shipped:

Queue-and-sync model. Students ask questions offline. App queues, syncs when signal arrives, pushes responses back.
On-device inference for basic queries. Distilled quantized model (~4B params) runs locally for ~30% of common requests. Zero connectivity required.
Selective sync with priority. Prioritize unanswered questions > content updates > analytics when the 15-minute window arrives.

Impact: session completion rate went from 34% to 88%.

Failure #4: What the AI Didn't Know About Students

First prompts were generic. Output was technically correct but culturally irrelevant. We'd explain algebra using apples and oranges to a student who'd never seen an orange. Chemistry with lab metaphors to students who'd never seen a Bunsen burner.

Fixed at the prompt layer:

Regional context injection. Every prompt includes the student's state, language, and region-appropriate analogies.
Textbook alignment. State boards use different textbooks. We pre-ingested Maharashtra Board, CBSE, UP Board syllabi.
Humility prompts. "If outside the standard textbook for the grade, say so and offer the closest related question." Reduced confidently-wrong answers by 80%.

Deployment Data

After 6 months in production:

2,400 students across 3 states.
~38K AI interactions per day at peak (mid-exam season).
~₹0.02 per interaction (after optimization).
Session completion rate: 88% (up from 34% at launch).
Voice input share: 76% of total queries.
Cached content hit rate: 89% during exam-prep weeks.

Monthly AI-serving cost per student: ~₹285. Target price ₹99/month. We lose money today but the trajectory works once we hit 10K+ students.

Five Lessons

Vernacular LLMs are a tokenization problem before they're a model problem. Fix tokens + prompts before picking a model.
Voice-first changes everything. If building for rural India, voice IS the interface.
Design for bursty connectivity. 15-minute-window sessions are the real use case.
Cultural context in prompts is not optional. Analogies matter more than raw model quality.
On-device + cloud hybrid is the only viable architecture. Neither alone works.

Where This Goes

Building AI for Bharat is not a translation problem. It's a systems problem involving tokenization, connectivity, UX modality, and cultural context — all of which need to be solved in concert.

At Xenotix Labs we've shipped 7S Samiti + Growara (WhatsApp AI automation) + Alcedo (AI-powered education discovery) — three different LLM-powered products for Indian users. Each taught us something that contradicted what the AI literature said would happen. If you're building AI solutions for startups in the Indian context, these failure modes are probably in your future. Getting ahead of them saves months.

Ujjawal Tyagi is the founder of Xenotix Labs, a product engineering studio that's shipped 30+ production apps including 7S Samiti (AI tutor for rural India), Growara (AI WhatsApp automation), and Cricket Winner (real-time cricket trading).

What It Actually Takes to Build AI WhatsApp Automation for Indian SMBs (Lessons From Growara)

Ujjawal Tyagi — Fri, 24 Apr 2026 10:42:36 +0000

Every Indian founder I've met in the last two years has the same WhatsApp problem. Customers DM them at all hours. Half the queries are the same five questions. The founder ends up being the company's unpaid, always-on customer support. At 50 customers a day it's manageable. At 500 it breaks the business.

We built Growara to solve this. It's an AI-powered WhatsApp automation platform — businesses plug it into their WhatsApp Business account and the AI handles FAQs, books appointments, escalates complex queries to humans, and goes quiet when it should. Sounds simple. Wasn't.

This piece is about what actually broke when we shipped it to Indian SMBs, the decisions that worked, and the ones we'd revisit.

The Lazy Assumption Everyone Makes

Before we started, every article I read about "AI WhatsApp bots" treated the problem as solved: "Just plug GPT into the WhatsApp Business API." I believed that for about two weeks.

Three things break that premise when you ship to real Indian SMBs:

1. Language. Indian customers don't chat in clean English. They chat in Hinglish — "bhai price kitne ka hai?" — or in full Hindi, Marathi, Tamil, or Gujarati, often in Roman script. Off-the-shelf LLMs handle English beautifully and Hinglish surprisingly well, but regional-language-in-Roman-script is a minefield. "Kya" is Hindi for "what," but depending on context the model sometimes reads it as a name.

2. WhatsApp's 24-hour window. WhatsApp Business API has a hard rule: after 24 hours of silence from the customer, you cannot message them first unless you use an approved template. Your bot CANNOT just "follow up tomorrow" without pre-registering a template with Meta and paying per-template fees. This one rule shaped half our architecture.

3. The "human handoff" edge case. The hardest question in any AI support system isn't "can the AI answer?" It's "how does the AI know when it can't?" Getting this wrong means either (a) an AI that gives confidently wrong answers, or (b) an AI that escalates everything and adds no value.

Our Actual Architecture

[WhatsApp user message]
     | (Meta Business API webhook)
[Node.js Gateway]
     |
[Message Classifier — small fine-tuned model]
     | branches to:
  |-- [Template Response] — for repeated FAQs (cached)
  |-- [LLM Response] — for freeform queries
  +-- [Human Handoff Queue] — for complex/ambiguous
     |
[WhatsApp Business API reply]

The classifier matters more than the LLM. Most queries — "What are your prices?" "Where are you located?" "When do you open?" — don't need an LLM at all. A small fine-tuned classifier (we use a distilled version of a multilingual BERT) catches them and returns a pre-written, founder-approved answer. Latency: 80ms. Cost: effectively zero. This handles about 65% of real message volume.

The LLM is only called for the hard 35%. When the classifier isn't confident, we go to the LLM with a heavily engineered prompt that includes business context, recent conversation history, and explicit escalation criteria.

The human handoff queue is the safety net. When the LLM's output is below a confidence threshold OR when certain red-flag keywords fire (price negotiation, complaint, payment issue), the message goes to a dashboard where the business owner replies from their browser. The AI never fakes confidence it doesn't have.

The Hinglish Problem, Solved

Our most-hated bug in the early weeks was the classifier confidently labeling "mujhe price batao bhai" as an appointment-booking request because the word "batao" appeared in some appointment training data.

What worked:

1. Fine-tune on real data, not synthetic. We bootstrapped with a few thousand messages from our own WhatsApp Business pilots. The gap between synthetic and real Hinglish was humbling.

2. Add a translation pass for the LLM. For the 35% that goes to the LLM, we first translate Hinglish/Marathi/Tamil into English using a small dedicated model, prompt GPT in English, then translate the response back. Three model calls instead of one. Latency bump ~600ms. Accuracy jump ~22 percentage points. Worth it.

3. Per-vendor terminology list. Each vendor onboards with a 20-term glossary (product names, service names, industry jargon) that gets prepended to every LLM prompt. Vendor-specific context beats bigger models.

The Handoff Threshold That Actually Works

The single highest-impact tuning decision we made: we set the LLM confidence threshold for human handoff aggressively high — meaning the AI hands off more readily than most teams would.

Counterintuitive? Yes. Customers would rather talk to a human than a wrong AI. Vendor satisfaction jumped when we reduced the AI's eagerness to answer edge cases. We also added four hard-coded handoff triggers:

Any message containing "refund", "complaint", "problem", "issue", or their Hindi equivalents.
Any numeric question about price >₹500 — our vendors' margins require human negotiation.
Any message after a previous human handoff in the same conversation.
Any message from a customer flagged as VIP.

These four rules alone improved our Net Promoter Score for the automation by 18 points.

What the Math Looks Like

For a typical vendor processing 500 WhatsApp messages per day:

65% handled by classifier alone: ~325 messages, near-zero marginal cost
25% handled by LLM after classifier miss: ~125 messages, ~₹3.50 per message
10% escalated to human: ~50 messages, vendor's own time

Monthly infrastructure cost per vendor: ₹3,000–5,000. Monthly LLM API cost: ₹13,000–15,000. We charge ₹25,000/month. The economics work because the classifier absorbs most volume.

Without the classifier — if we sent every message to GPT — cost per vendor would be ~₹45,000/month and the product wouldn't exist.

Five Lessons Compressed

The AI is never the hard part. The WhatsApp Business API, the language edge cases, and the handoff UX consumed 80% of engineering time.
Small models beat big models on tight-context tasks. A fine-tuned classifier for intent routing is cheaper, faster, and more accurate than calling GPT-4 for every message.
Hinglish needs real data. Synthetic training sets lie to you. Pay to collect real conversation logs from pilot vendors before shipping.
Design for the 24-hour window from day one. Templates aren't an afterthought — they're a core data model.
Hand off more, not less. Customers forgive a human-in-the-loop AI. They don't forgive a confidently wrong AI.

Taking the Leap

If you're an Indian SMB tech team thinking about building something similar, the path is real but narrower than the marketing suggests. You need a ruthless focus on the top 20 FAQs your customers actually send, real conversation data before you train anything, an explicit human-handoff UX that your vendors actually want to use, a template library per vendor registered with Meta, and a classifier-first architecture where LLMs are the expensive exception, not the default.

At Xenotix Labs we've built this stack — Growara is one of several AI solutions for startups we've shipped. If you're exploring WhatsApp automation as part of your product roadmap or looking at MVP development services for startups, the patterns above apply whether you build with us or roll it yourself.

AI WhatsApp bots are a real product category in India. The teams that win are the ones honest about where the AI stops working.

Ujjawal Tyagi is the founder of Xenotix Labs, a product engineering studio that's shipped 30+ production apps including Growara (AI WhatsApp), Cricket Winner (real-time cricket trading), and 7S Samiti (AI tutor for rural India).

From Figma to Production in Six Weeks: The Design-to-Code Pipeline We Use to Ship Flutter Apps

Ujjawal Tyagi — Fri, 24 Apr 2026 10:07:15 +0000

Every Flutter team has the same broken ritual. The designer finishes a beautiful Figma file. The developer opens it, stares at a spacing value of "14.3px", sighs, and rebuilds the UI from scratch. Three weeks later, the product ships with colors and paddings that don't match the design. The designer files a bug. The developer pushes back. Trust breaks down. The next project is worse.

This is solvable. Over the last two years, we've shipped more than twenty production Flutter apps at Xenotix Labs, and we've built a design-to-code pipeline that gets us from final Figma to staging build in six working weeks on most projects. Not because our designers and developers are faster than yours — they aren't — but because the handoff is engineered, not improvised.

This is the pipeline. If you're a founder tired of design drift, or a developer tired of rebuilding the same components from scratch, or a designer tired of being told "it'll be fine in development", this is for you.

The Core Principle: Design Tokens Are a Contract

Most teams treat Figma files as a picture of the app. That's the wrong mental model. A Figma file is a contract between design and engineering. Contracts are machine-readable. Pictures aren't.

Before we start any new project at Xenotix Labs, we spend three days — not more, not less — on what we call the token foundation. This is a Figma library that defines:

Color tokens: never named Red_500. Always named by role: color/surface/primary, color/border/danger, color/text/on-inverse. The designer picks the hex; the role is what the developer consumes.
Spacing scale: a rigid 4-point or 8-point grid. No "14px" spacing allowed, ever. If designers need 14, they pick 12 or 16.
Typography ramp: 6–8 text styles, each with font family, weight, size, line-height, and letter-spacing. Named by role (text/heading/large, text/body/default).
Radius and elevation scales: same rigor. Discrete steps, named by role.

This foundation takes three days because most design teams have never built one, and most dev teams have never asked for one. Once it exists, the handoff becomes deterministic.

Step 1: Figma to Tokens Studio to JSON

We use the Tokens Studio plugin for Figma to export our tokens as JSON. The output looks like this:

{
  "color": {
    "surface": { "primary": { "value": "#0F172A" } },
    "text": { "on-inverse": { "value": "#F8FAFC" } }
  },
  "spacing": { "4": { "value": "16" }, "6": { "value": "24" } },
  "radius": { "md": { "value": "12" } }
}

This JSON gets checked into the app's repo, in a folder called design-tokens/. It's version-controlled. It has its own PR review process. Designers can push updates.

Step 2: JSON to Flutter Theme Extensions

We've written a small Dart generator (it's about 200 lines, nothing clever) that takes the tokens JSON and emits strongly-typed Dart code:

class AppColors {
  const AppColors._();
  static const surfacePrimary = Color(0xFF0F172A);
  static const textOnInverse = Color(0xFFF8FAFC);
}

class AppSpacing {
  const AppSpacing._();
  static const s4 = 16.0;
  static const s6 = 24.0;
}

And we register these as a ThemeExtension on the Flutter ThemeData, which means developers can pull tokens out of context like this:

final colors = Theme.of(context).extension<AppColorsExt>();
return Container(color: colors.surfacePrimary);

This is the critical moment. From here on, developers cannot type hex codes into the app code. Our linter catches it. Pull requests get blocked. The only way to add a new color is to add it to the Figma token library, regenerate, and ship.

The outcome: design drift becomes mechanically impossible.

Step 3: Component Library - Built Once, Used Everywhere

After tokens, we build a shared component library in Flutter — around 40 to 60 components, depending on the project. Buttons, input fields, cards, chips, modals, bottom sheets, app bars, typography components. Each one consumes tokens, not raw values.

We version the component library as its own internal package. For a project like Veda Milk (the D2C dairy subscription platform we built), the end-user app and the delivery-boy app both depend on version 1.8.3 of the shared component library. When we update the button component, both apps pick it up on next build. One source of truth.

Developers don't build screens from Figma. They build screens by composing components from the library. If a component they need doesn't exist, they don't invent one — they propose it. It gets added to the library, reviewed by a designer, and then used.

This is the shift that gets us from "twelve weeks" to "six weeks" on most projects. Most Flutter development time gets burned rebuilding buttons, input fields, and cards for the fifth time. Once the component library is solid, developers assemble screens in hours, not days.

Step 4: The Handoff Ritual

Every screen goes through a 15-minute handoff call between the designer and the assigned developer. Not a long meeting. A short, structured one. The developer opens the Figma file. The designer walks them through:

Which components are reused, which are new.
Any states not immediately visible (empty state, error state, loading state, skeleton).
Any animations (we document these in a separate Framer or Principle file, not left to imagination).
The "one weird thing": every screen has one non-obvious interaction. Surfacing it upfront costs 30 seconds and saves two days.

We log this call in a one-page doc in Notion. Developer signs off ("I understand everything here"). Designer signs off ("I've covered everything"). If a bug surfaces later that one of them missed, it becomes a learning moment for the ritual, not a blame moment for the person.

Step 5: The Three-Pass Review

Every screen goes through three reviews before it ships to staging:

Pass 1: Pixel review. Developer takes screenshots of the built screen and overlays them on the Figma frame in Figma Jam or Eagle. Diffs over 2 pixels get fixed. This takes 5 minutes per screen.

Pass 2: Interaction review. Designer plays with the built screen on a real device. Not the simulator. A mid-range Android and an iPhone. This is where you catch "the button hit area is too small" or "the loading shimmer flickers when the screen loads fast."

Pass 3: Production-state review. QA runs the screen through real data — empty lists, 200-character names, missing images, bad network. This is where most Flutter apps visibly fail in App Store reviews. Catching it internally saves a review rejection cycle.

Step 6: The Continuous Design QA Loop

Once the app is in staging, we run a weekly Design QA pass. The designer opens the app for an hour, notes everything that feels off, and files tickets. These tickets are labeled design-qa, tagged to the designer and a developer, and don't count against the feature backlog — they're treated as debt, paid down every sprint.

This is how we avoid the classic pattern where the app ships and then feels 80% right for the rest of its life. Design QA is a practice, not an event.

The Tech Stack That Makes This Possible

For anyone trying to build this pipeline:

Design tooling: Figma + Tokens Studio plugin + Storybook-equivalent (we use Widgetbook for Flutter).
Code tooling: Dart token generator, Flutter ThemeExtension, strict linter rules (avoid_hardcoded_colors), Melos for monorepo packages.
Review tooling: Figma Jam for pixel diff overlays, Eagle for screenshot comparisons, Notion for handoff docs.
CI/CD: Every PR runs a visual diff test (we use golden tests) that flags any screen where pixels have shifted without an accompanying design update.

None of these tools are exotic. The discipline is what's rare.

What Six Weeks Looks Like in Practice

To make this concrete, here's the timeline for a typical Xenotix Labs project — say, a two-sided marketplace mobile app:

Week 1: Token foundation + component library skeleton + Figma sign-off on flows.
Week 2: 70% of components built and in Widgetbook. Screens start getting composed.
Week 3: First 12 screens complete, first pixel review pass, first interaction review.
Week 4: Remaining screens, state handling, empty/error/loading states.
Week 5: Integration with backend APIs, real data testing, production-state review.
Week 6: Design QA pass, App Store / Play Store submissions, staging-to-production migration.

Six weeks. Two designers, two developers, one QA. A shippable production app that matches the Figma file within 2 pixels on every screen.

The Real Unlock Isn't Speed - It's Trust

The pipeline above sounds like it's about speed. It isn't. It's about trust.

When designers and developers trust each other, they ship better work. When they don't, they ship compromised work and gradually dislike each other. The pipeline isn't there to make development faster. It's there to remove the friction points that cause teams to distrust each other.

Six weeks is a byproduct. The product is mutual respect.

Where to Go From Here

If you're a founder looking at a Flutter build and wondering how to avoid the design-drift disaster, there are three things you can do tomorrow:

Make the design tokens a contract. Don't start coding until the token library is locked.
Build the component library before the first screen. It feels slow on week one. It pays back threefold by week three.
Institute the three-pass review. Pixel, interaction, production-state. Every screen. No exceptions.

If you want the pipeline built for you — or you're looking at a product roadmap and want a team that already operates this way — you can browse our full-stack development services or read how we've applied this to 30+ production apps including Veda Milk, Cricket Winner, and Nursery Wallah. If you're hiring in India and want to skip the ramp-up, we also offer an option to hire React Native developers in India who already know this workflow.

Good design-to-code is engineered. The teams that get it right aren't smarter than the ones that don't. They're just a little more disciplined about the contract.

Ujjawal Tyagi is the founder of Xenotix Labs, a product engineering studio building mobile apps, web platforms, and AI solutions for startups. His team has shipped 30+ production apps using the Figma-to-Flutter pipeline described above.

The Real Engineering Cost of Scaling an Indian Cricket App From 1K to 1M Users on Kafka

Ujjawal Tyagi — Fri, 24 Apr 2026 10:03:36 +0000

Most engineering blogs that talk about Kafka either quote the Netflix case study or walk you through the "hello world" producer-consumer example. Both are useless if you're actually trying to decide whether to adopt Kafka for a product that might hit a million users — or stay at ten thousand forever.

This is a story from the trenches of building Cricket Winner, a real-time cricket scores, news, and opinion-trading platform for the Indian market. I'll walk through the decisions we made, the decisions we got wrong, and the numbers we wish someone had shared with us when we started.

The Product, in One Paragraph

Cricket Winner does three things in real time: it streams live ball-by-ball updates during matches, pushes breaking cricket news as it happens, and runs an opinion-trading engine where users take positions on outcomes ("Will Kohli score a fifty this innings?"). During an India vs. Pakistan match, a single over can produce a burst of 40,000+ user actions — upvotes, trades, opinion updates, comment floods. The rest of the time, the system sits idle.

That bursty profile is why we chose Kafka. It's also why we almost abandoned Kafka three months in.

The Decision That Nearly Killed Us

When we started, our backend was a monolithic Node.js service with a PostgreSQL database and WebSockets for live updates. It worked fine for 5,000 concurrent users during beta testing with a state-league match. Then the first IPL match hit production, we crossed 60,000 concurrent users in the first 20 minutes, and WebSocket connection storms took the entire app down for 90 minutes.

The post-mortem was simple: our "real-time" architecture was secretly synchronous. Every ball update had to fan out through the same Node process that was also handling auth, trading settlements, and news dispatch. One slow database query anywhere in the chain backed up every single live connection.

We had two options:

Add more Node instances behind a load balancer (classic horizontal scale) — but our database was a single Postgres instance, so we'd just be moving the bottleneck.
Decouple the real-time pipeline from the transactional pipeline using an event-driven architecture.

We picked option 2. That meant Kafka.

Why Kafka and Not RabbitMQ

This is the question we get most often from other Indian dev teams. We already used RabbitMQ on another project (Veda Milk, a D2C dairy subscription platform) and we'd been happy with it. So why not reuse it?

Three reasons:

Throughput ceiling. RabbitMQ peaks at ~50K messages/sec per node in practical Indian cloud setups. Kafka comfortably does 500K+ on the same hardware. During a cricket match final, we've hit 180K messages/sec sustained. RabbitMQ would have fallen over.

Replay. During an outage (and there will be outages), Kafka lets you replay the event log. That matters a lot when your opinion-trading engine crashed mid-match and you need to reconstruct user positions from the last 30 minutes of events. RabbitMQ is a "fire and forget" queue — once a message is acked, it's gone.

Fan-out topology. In our system, a single "ball bowled" event needs to reach four consumers simultaneously: the live score broadcaster, the trading settlement engine, the notification dispatcher, and the analytics pipeline. Kafka's consumer group model handles this natively. With RabbitMQ you end up creating exchange-bindings that get complex fast.

For Veda Milk we kept RabbitMQ — it's a D2C subscription platform where order volume is high but bursts are small and replay doesn't matter. Right tool for the right job.

The Architecture We Actually Ship

Here's our production topology, simplified:

[Mobile/Web client]
     | (WebSocket)
[API Gateway — Node.js + Socket.io]
     | (Kafka producer)
[Kafka cluster — 3 brokers, AWS MSK]
     | (Kafka consumers)
  |-- Live score service (publishes to socket rooms)
  |-- Trading engine (writes positions to Postgres)
  |-- Notifications (pushes FCM/APNs)
  |-- Analytics (writes to ClickHouse)
  |-- News dispatcher (fan-out to feed service)

Each consumer is its own microservice, deployed independently on ECS. When the trading engine deploys a new version, the live scores keep streaming. When the news dispatcher has a bug, it can be restarted without affecting anything else. Before this decoupling, a single deployment would cause a 15-second read-availability blip for everyone.

The Cost That Nobody Tells You About

Every Kafka blog post glosses over this: operating Kafka is not free, and it's not easy.

Our AWS MSK bill for Cricket Winner alone runs ₹85,000–₹1,10,000/month (approximately $1,000–$1,300). That's for a 3-broker cluster (kafka.m5.large), with replication factor 3. On top of that, we run self-managed Zookeeper for historical reasons (newer MSK versions use KRaft, we're migrating).

The human cost is bigger. You need at least one engineer on the team who understands:

Consumer-group rebalancing dynamics (what happens when a consumer crashes mid-partition-assignment).
Partition key selection (we partition by match_id, not user_id — took us a month to figure that out).
Exactly-once vs at-least-once semantics and how to write idempotent consumers.
How to debug a lagging consumer at 2am when India is beating Australia in the final.

If you don't have that engineer, or can't hire one, Kafka will punish you. The "hello world" Kafka is lovely. Production Kafka has sharp edges.

What We'd Tell Our Past Selves

Five lessons, compressed:

1. Don't adopt Kafka until you actually need it. Before we had 50K+ concurrent users, RabbitMQ + good database indexes would have been plenty. We jumped to Kafka slightly too early. The complexity tax was real.

2. Partition keys are everything. Your throughput, your ordering guarantees, and your consumer parallelism are all downstream of this one decision. Spend a week thinking about it before you ship.

3. Write idempotent consumers from day one. You will reprocess events. You will redeploy during a match. You will have duplicates. If your consumer isn't idempotent, every one of those events will corrupt state.

4. Monitor consumer lag, not throughput. Throughput tells you what happened. Consumer lag tells you what's about to break. We added lag alerts on day 40 of production; we should have added them on day 1.

5. The "Kafka vs. RabbitMQ" debate is a false dichotomy in real systems. We run both. Kafka for high-throughput event streams that need fan-out and replay. RabbitMQ for work queues and background jobs. Use the right one for the right job.

What's Actually Possible in the Indian Market

If you're a founder reading this and wondering whether your app needs this kind of architecture — here's the honest answer:

You need Kafka if: you're building real-time (gaming, trading, cricket, live sports, live commerce), your traffic has 10x+ spikes, and you need to fan out the same event to 3+ downstream systems. Cricket Winner, FYZ (short-video), Bolcall (dating app with live calls) all fit this profile.

You don't need Kafka if: you're building a marketplace, a standard e-commerce site, a services platform, or an internal B2B tool. RabbitMQ is enough. We built Veda Milk, Nursery Wallah, Cremaster, Housecare, Abomed, My Shaadi Store, and Prepe — all subscription or marketplace products — on RabbitMQ and none of them have needed Kafka.

The cost of over-engineering is real. The cost of under-engineering only hits you once, but it hits you hard. Get it right the first time by being honest about what you're actually building.

Taking the Leap

Building a real-time platform in India is different from building one in the US. Our users have flakier connectivity, lower tolerance for lag, and usage patterns that cluster around a few moments (the ball, the goal, the finale) rather than distributing evenly through the day. That shapes your architecture in ways Western tech blogs don't capture.

If you're evaluating whether to go monolith vs microservices, or RabbitMQ vs Kafka, for your next product — the answer is almost always "start simpler than you think, and decouple only when the pain is real." That's the path we took at Xenotix Labs, and it's the path we'd take again. You can browse more of our engineering case studies in our software development case studies — including the full Cricket Winner teardown — or read about the full microservices and Kafka stack we use across our builds.

The boring truth about production systems is that the best architecture is always the simplest one that works. Kafka is a fantastic tool. It's also a sharp one. Use accordingly.

*Ujjawal Tyagi is the founder of Xenotix Labs, a product engineering studio that's shipped 30+ production apps across Flutter, Next.js, and Node.js for Indian and international startups. Case studies include Cricket Winner (real-time trading on Kafka), Veda Milk (D2C dairy on RabbitMQ), and Growara (AI WhatsApp automation).

30 Products in 4 Years: Our Flutter + Next.js + Node.js Playbook

Ujjawal Tyagi — Fri, 24 Apr 2026 09:41:17 +0000

At Xenotix Labs (https://www.xenotixlabs.com), we've shipped 30+ production apps in 4 years across D2C, edtech, fintech, healthtech, SaaS, and marketplaces. Every single one followed the same playbook.

The Stack

Flutter for mobile (iOS + Android in one codebase)
Next.js for web (SSR for SEO)
Node.js + PostgreSQL/MongoDB for backend
RabbitMQ for background jobs, Kafka for high-throughput streams
Microservices on AWS from day one

Case Studies

Veda Milk — a Country Delight-style D2C dairy subscription platform with three apps: end-user, delivery boy, admin panel. RabbitMQ handles daily subscription cycles.

Cricket Winner — real-time cricket scores plus opinion trading. WebSockets for live sync, Kafka for news ingestion.

Legal Owl — a LegalTech super-app. Courses, community, journals, and an Advisor Hub where users can call a lawyer from inside the app.

Growara — AI WhatsApp automation. Meta Business API + LLM. 24/7, no manual effort.

ClaimsMitra — insurance survey platform with 114+ REST API endpoints.

7S Samiti — AI tutor for rural India. Offline-first Flutter, LLM-powered adaptive learning.

What We Don't Do

Hourly billing — fixed scope, milestone-based
PM handoffs — founders stay in the WhatsApp group
Skip testing — unit → integration → production is non-negotiable
Use templates

If you're building something, talk to us at https://www.xenotixlabs.com.