DEV Community: Ujjawal Tyagi

Postgres at Scale: Lessons from Running 30+ D2C Platforms on RDS

Ujjawal Tyagi — Wed, 06 May 2026 14:50:29 +0000

PostgreSQL is the database we reach for first at Xenotix Labs. We've shipped 30+ platforms on it across D2C dairy (Veda Milk), service marketplaces (Cremaster, Housecare), insurance survey workflows (ClaimsMitra), legal-tech (Legal Owl), and more. None of those projects ran into a wall where Postgres couldn't keep up. But several of them ran into walls where we couldn't keep up with Postgres — not knowing how to use the indexes, the connection pool, the query planner, or the vacuum settings. Here are the lessons that landed.

Lesson 1: connection pooling is non-optional

The default Postgres max_connections on RDS is 100 (sometimes scales with instance size). A Node.js app server with 4 workers easily opens 4 connections per process; deploy 8 servers and you've eaten a third of your pool.

Fix: PgBouncer in transaction-pooling mode in front of every cluster. Each app server now holds a small pool of cheap PgBouncer connections, and PgBouncer multiplexes them onto a much smaller pool of real Postgres connections. We run with 200–1000 client connections and 20–40 actual Postgres connections.

Note: transaction pooling means you can't use session-level features like SET LOCAL in a way that survives across statements, prepared statements get tricky, and LISTEN/NOTIFY doesn't work well. Plan around this from day one.

Lesson 2: indexes that don't get used are a tax

Every index speeds up reads and slows down writes. We've found unused indexes that were costing us 15% on write throughput and zero on read latency. Find them and drop them.

SELECT schemaname, relname, indexrelname, idx_scan, pg_size_pretty(pg_relation_size(indexrelid)) AS size
FROM pg_stat_user_indexes
WHERE idx_scan = 0
  AND indexrelname NOT LIKE 'pg_toast%'
ORDER BY pg_relation_size(indexrelid) DESC;

Run it monthly. Drop anything that's been zero scans for 90+ days and isn't unique-constraint enforcement.

Lesson 3: partial indexes for the hot path

Our Veda Milk subscription engine queries "all subscriptions where the next delivery is tomorrow." Indexing every subscription on next_delivery_date works but is wasteful — 95% of subscriptions don't have tomorrow as their next delivery.

A partial index, only on rows that match the hot predicate, gets us a 10x smaller index:

CREATE INDEX subs_due_tomorrow_idx
ON subscriptions (next_delivery_date)
WHERE status = 'active' AND next_delivery_date >= CURRENT_DATE;

The planner picks this automatically when our nightly job queries with the matching predicate.

Lesson 4: vacuum tuning is where you find dragons

Default autovacuum settings are fine for normal tables. They're terrible for high-churn tables like wallet ledgers and order tables in subscription commerce.

For those, we tune per-table:

ALTER TABLE wallet_ledger
SET (autovacuum_vacuum_scale_factor = 0.05,
     autovacuum_analyze_scale_factor = 0.02);

Default is 0.2 (vacuum when 20% of rows are dead). For tables with a million writes a day, 0.2 means waiting 200k dead tuples before vacuum. Bloat builds. Indexes degrade. Reads slow.

Lesson 5: read replicas for analytics, never for primary reads

We used to route some "non-critical" reads to a read replica. It bit us when replica lag spiked during a heavy write burst and customers saw stale balances.

Now the rule: read replicas are for offline-style analytics queries (BI dashboards, reports, ML feature pipelines). Customer-facing reads always come from the primary, with caching in Redis or the application layer if latency matters.

Lesson 6: JSONB is not a free lunch

We've seen teams treat JSONB like a schemaless escape hatch. "We don't know the shape yet, let's just store JSON." 18 months later, every query has 4 JSONB extractions and 2 GIN indexes that are 5 GB each.

Use JSONB for genuinely sparse, nested, or polymorphic data — audit logs, event payloads, third-party API responses. For business entities with predictable schemas, use real columns. The future you will thank present you.

Lesson 7: backups are easy, restores are hard

RDS automated backups are great until you need to restore one. We test restores quarterly:

Spin up a new cluster from the latest snapshot
Connect a non-prod copy of the app
Run the smoke-test suite
Time how long the entire process took

The first time we did this, restore took 4 hours and the smoke tests revealed two missing migrations in the snapshot. Now restore takes 45 min and we know the process works.

Lesson 8: migrations need a rollout playbook, not just a tool

Long-running migrations on tables with millions of rows can lock the table for minutes. We use a playbook:

Schema-only changes (CREATE INDEX CONCURRENTLY, ADD COLUMN with default null): safe at any time
Data backfills: run in batches via a one-off worker, monitor lag, never block the primary connection pool
Type changes: use a multi-step pattern — add new column, dual-write from app, backfill, switch reads, drop old column over multiple deploys

Never use a migration tool's "apply" button on a table that has more than 1M rows without checking what it actually does first.

Lesson 9: query_text is your friend

pg_stat_statements is enabled on every cluster we operate. The queries that show up at the top of total_time after a week of production usage are exactly the queries that need indexing, batching, or rewriting. Read pg_stat_statements weekly, you'll out-pace anyone debugging in production.

Stack we ship with PostgreSQL

Backend: Node.js (with pgbouncer in front)
Migrations: node-pg-migrate or knex with peer-reviewed migration scripts
Connection pool: pgbouncer (transaction mode), node-postgres pool per service
Backups: RDS automated + monthly logical dumps to S3
Monitoring: CloudWatch + pg_stat_statements dashboards
Replicas: RDS read replica for analytics workloads

Building a product where Postgres has to scale?

We've shipped 30+ Postgres-backed products without hitting a wall. Most teams don't because they don't know what to look for. If you're building one, Xenotix Labs has the playbook for setup, scaling, and surviving the next round of growth. Reach out at https://xenotixlabs.com.

Build vs Buy: Authentication for Indian D2C Apps

Ujjawal Tyagi — Wed, 06 May 2026 14:47:57 +0000

Auth0 costs ~$0.023 per active user per month at the volumes most Indian D2C startups operate at. For a brand at 100,000 MAU that's ~$2,300/month. For a 1M MAU app, it's ~$23,000/month. Which is fine if your gross margin per user is $5+. It's not fine if your average customer spends ₹300 a month on milk subscriptions.

This is the calculation that drives most of our Xenotix Labs backend decisions. Build the auth system, save the recurring fee. Buy the auth system, save 4 weeks of engineering. The right answer changes by company, and we've made both calls. Here's the framework we use.

What auth actually has to do for an Indian D2C app

Phone-OTP login (the default for India, not email/password)
Email/password as a fallback for older / NRI users
Social login (Google primarily; Apple for iOS users with iCloud accounts)
Magic link via WhatsApp or email
Session management with refresh tokens
Multi-device login + remote logout
Account recovery via the original phone OR email
Rate limiting on OTP requests (a single phone shouldn't be OTP-bombed by attackers)
DPDP Act compliance (consent storage, data retention, deletion requests)
Audit logging for compliance

If your auth provider doesn't natively support all of those, you're paying their monthly fee AND building chunks of auth on top. Worst of both worlds.

When to buy (Auth0, Clerk, Supabase Auth)

Buy when one of these is true:

You're under 50,000 MAU and time-to-launch beats running cost
Your team has zero security engineering experience and you need someone else to take responsibility for the basics
You need SSO/SAML for B2B customers (rolling SAML yourself is an unforced error)
You're integrating with HRIS, IDPs, or other enterprise identity systems

The real reason to buy isn't "auth is hard." It's that good auth is hard — password-spray rate-limiting, breach-list checks, device fingerprinting, ATO detection. A modest team will not match what Auth0 or Clerk does on those.

When to build

Build when one of these is true:

Your unit economics can't absorb the per-MAU fee at your projected scale
You need OTP delivery via Indian SMS gateways (Auth0's global pricing models are wrong for Indian SMS volumes)
You need WhatsApp OTP, which is often cheaper than SMS in India and which most non-Indian providers don't natively support
You need consent flows specific to DPDP Act / state regulations
You're operating at 1M+ MAU and your fee is a six-figure-per-month line item

What "build" actually means

It does not mean writing JWT signing from scratch. It means:

Use a battle-tested library for password hashing (Argon2 via your language's standard wrapper)
Use jsonwebtoken or your stack's standard JWT library for token issuance
Use a vetted OTP provider (MSG91, AWS SNS, or WhatsApp Cloud API for Indian volumes)
Build the orchestration: registration flow, login flow, OTP issuance/verification, session management, refresh tokens, password reset, social login OAuth dance
Build the security perimeter: rate limits, lockouts, account-takeover detection, breach-list checks (haveibeenpwned k-anonymity API)
Build the compliance layer: consent timestamps, deletion workflows, audit logs

For a senior engineer this is 4–6 weeks of focused work. For a junior team it's 12+ weeks and you'll miss things. The rule we use: if your bench has a senior engineer who has previously shipped auth in production, build. If not, buy.

The architecture we keep using when we build

client → API Gateway → auth-service
                          ↓
                  ┌───────┼─────────┐
                  ↓                  ↓
             OTP provider     PostgreSQL (users, sessions, audit_log)
                  ↓                  ↓
            Redis (rate limit + OTP TTL)

Stateless JWT access tokens (15-min TTL)
Stateful refresh tokens (90-day TTL, stored hashed in PostgreSQL with a one-time rotation rule)
Per-phone OTP rate limit (max 5/hour, exponential backoff thereafter)
Breach-list check on every password set/change (haveibeenpwned k-anonymity)
Argon2id for password hashing with reasonable cost parameters
Audit log entry for every auth event (login, logout, password change, MFA enroll, etc.)

Common mistakes

Storing OTPs in plaintext. Hash them like passwords with a short TTL.
Generating tokens without rotation. A leaked refresh token should self-revoke when used twice.
Forgetting to invalidate sessions on password change. Otherwise an attacker who held a session continues to hold it.
Using v4 UUIDs as session IDs. They're not random enough for some threat models. Use 128 bits of crypto-random base64.
Letting phone numbers be the only identifier. Phone numbers get recycled in India. Bind sessions to a stable user_id, not the phone.

Building auth (or any other piece of D2C infrastructure)?

When the unit economics force you to build vs buy your auth, Xenotix Labs has shipped both kinds. We've integrated Auth0, Clerk, Supabase Auth, and built custom phone-OTP systems for Indian-volume apps. Reach out at https://xenotixlabs.com.

Building an AI Tutor for Rural India: What Works at 2G Speed

Ujjawal Tyagi — Wed, 06 May 2026 14:31:07 +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 adaptive AI tutor for rural Indian students, taught us that this approach gets you maybe 5% of the way to a working product.

The other 95% is engineering for the actual constraints of rural India: a ₹1,500 phone, 32 GB of total storage shared with WhatsApp and the camera, 2G most of the day with bursts of 4G when the family travels to the nearest town, and a primary user who is either bilingual in Hindi-English Roman script or wants to interact entirely in voice.

Here's what we learned at Xenotix Labs.

Constraint 1: storage is the gatekeeper

The phones our users own do not have room to download a 600 MB app. They barely have room for our 80 MB app. We hit storage limits constantly.

Fix: split the app into a tiny installer (~20 MB) plus on-demand content packs that the user can opt into per subject. When a student finishes Class 8 Mathematics, the next time they have Wi-Fi at school, the Class 8 Science pack downloads. When they finish Science, Math is auto-evicted.

This is uncomfortable engineering. You have to track which content is on which device, which device has been seen recently, and which packs the student is most likely to need next. We log usage telemetry (locally first, synced when possible) to drive eviction policy intelligently.

Constraint 2: 2G changes everything

A 2G connection is ~50 KB/s on a good day. A 1 MB image takes 20 seconds. A 5 MB video takes 100 seconds.

We stopped using images for anything that could be expressed in HTML/CSS. Math equations: KaTeX, not screenshots. Diagrams: SVG, not raster. Animations: pre-rendered Lottie JSON files (smaller than GIFs), often under 50 KB.

Videos for lessons are streamed at 240p with adaptive bitrate. Each lesson has a "text-only" fallback the student can toggle on a slow day.

Constraint 3: voice over text

Our primary users are 11- to 14-year-olds who are still building literacy. Typing English on a touchscreen is slow. Typing Hindi via transliteration is even slower. Voice is faster, more natural, and more accessible.

We use on-device speech-to-text where possible (Android's offline STT works surprisingly well for Hindi-English code-switching), with a server fallback when local fails. The student speaks their question, the AI tutor responds with both audio and text. The text is there for re-reading; the audio is there for first comprehension.

Voice has a free side-effect: it's the only way the app works for partially-literate users. We didn't plan for that audience initially. They became 12% of monthly active users.

Constraint 4: the LLM in the middle

The AI tutor generates personalized quizzes, explanations, and study notes from the student's question. Standard LLM territory. The complications:

Latency. A 4-second LLM response feels instant on Wi-Fi and unbearable on 2G. We stream the response token-by-token, even on 2G. The student sees the first words within ~1 second; the rest fills in as the network allows.
Cost. A 7B-class self-hosted model handles 60% of queries; we route only the hard ones to a frontier model. Per-user daily token budget capped at the level a self-supporting student would tolerate.
Curriculum alignment. The tutor must stay aligned with NCERT (or equivalent state board) curriculum. We retrieval-augment every prompt with the relevant chapter context from a vector store of textbook content the student has selected.
Hallucination is a child-safety issue. A wrong math answer is bad. A wrong history fact is worse if a child memorizes it. We never let the LLM answer factual questions without retrieved context, and we surface a "I'm not sure" UI when confidence is low.

Constraint 5: offline is the default

The app must work entirely offline for the first 3 days. Otherwise, families with limited mobile data won't enroll their kids.

When the student installs the app, the installer downloads the first 50 lessons of the chosen subject and the on-device classifier model. From there, the AI tutor can generate quizzes, score them, and explain answers entirely on-device using a small distilled model.

The more capable LLM kicks in when the network is available. The student doesn't notice the boundary; lessons feel continuous regardless.

Constraint 6: trust is built in person

You cannot acquire users in rural India through Instagram ads. The trust gap is too wide. We work with local school teachers, NGOs, and panchayat-level community members. Our "onboarding" is a 30-minute session at the school where a teacher walks 10 students through their first lesson together.

We ship features for those teachers: a teacher dashboard (works on a basic Android), bulk-enroll flows, classroom-mode that mirrors a student's screen so the teacher can help with a stuck question. These features have nothing to do with AI; they're 100% of why the AI works in the field.

Stack summary

Mobile: Flutter (offline-first, ~80 MB base + on-demand content packs)
Web: Next.js (teacher and admin dashboards)
Backend: Node.js + PostgreSQL
AI Layer: mix of on-device distilled model + self-hosted 7B for routine + frontier model for hard
Speech-to-text: Android offline STT primary, server fallback
Content: SVGs, KaTeX, Lottie, 240p adaptive video
Architecture: Microservices (auth, content, tutor, telemetry)
Deployment: AWS
Testing: Unit → Integration → Production + airplane-mode QA + 2G emulation

What we'd tell other teams building for emerging markets

Storage budget is your #1 design constraint. Build for 100 MB total or you're not in the game.
Voice is a feature, not a nice-to-have. Often, it's the entire UX.
Cache aggressively, evict gracefully. Show the student progress on what's downloading.
Test on the actual phone. Borrow a friend's old Redmi 7. Open the app there. Cry. Fix.
Build for offline-first. Sync is second. Reverse this and you'll burn months.
Local trust is the acquisition channel. Engineer for the teachers who'll evangelize you.

Building for emerging markets, rural India, or low-resource environments?

The playbook for premium-market apps is different from the playbook for budget-phone, low-bandwidth, partially-literate audiences. If you're building in this space, Xenotix Labs has shipped Flutter apps across rural education, dairy delivery, and field-work apps. Reach out at https://xenotixlabs.com.

Building a LegalTech Super-App: Mapping 7 Personas in Figma Before Writing Code

Ujjawal Tyagi — Wed, 06 May 2026 14:28:18 +0000

Most LegalTech apps are course platforms with a chat bolted on, or chat platforms with a forum bolted on. We built Legal Owl at Xenotix Labs as a real legal-education super-app: structured courses, a community forum, legal journals, and an Advisor Hub where users talk to lawyers via in-app voice or scheduled appointment. Seven distinct user personas, one product.

The biggest decision we made on Legal Owl wasn't an architectural one. It was a Figma one: we spent three full weeks mapping all seven personas in Figma before any engineering started. Here's why, and the architecture that followed.

The seven personas

Law student — wants courses, study notes, exam prep, peer community
Practicing junior lawyer — wants advanced courses, case-law journals, mentorship
Senior lawyer offering paid time — wants a clean booking system, payouts, calendar control
Volunteer lawyer answering free questions — wants moderation tools, batched responses
End-user with a legal question — wants quick anonymous answers + paid escalation
Course author — wants authoring tools, royalty reports, student feedback
Platform admin — wants moderation queues, payout management, analytics

Notice: a single "user" can occupy multiple personas at once. A practicing lawyer can also be a course author and a senior lawyer offering paid time. The persona is a role, not an identity.

Why three weeks in Figma

If we'd started building immediately, we'd have shipped an MVP for personas 1 and 5 (the easiest two), then spent 6 months retrofitting the rest. By mapping all seven up front, we caught dozens of cross-persona conflicts before they became code:

Course authors and senior lawyers both need a "my earnings" view — one source of truth, two entry points
Volunteer lawyers shouldn't see "paid escalation" prompts; the same question UI must hide one button based on context
Admins need to see everything but never become a bottleneck for routine moderation — community moderators handle it day-to-day

These conflicts are designed in Figma. They're impossibly painful to refactor in code.

The role system

After Figma, we modeled the data:

users
  id, name, email, phone, ...

user_roles
  user_id, role_type (student | junior_lawyer | senior_lawyer | volunteer | end_user | course_author | admin)
  granted_at, granted_by, status, ...

role_capabilities
  role_type, capability (e.g. 'create_course', 'moderate_forum', 'accept_paid_call')

A user can hold multiple roles. The UI checks role_capabilities, never role_type directly. "Can this user create a course?" is user has any role with capability 'create_course'. Adding a new role tomorrow is data, not code.

The Advisor Hub: real-time voice + scheduled calls

The in-app voice call between a user and a lawyer is two-way audio with on-screen call controls and post-call notes. We use WebRTC for the audio path and a signaling service over WebSockets for setup.

The complications nobody warns you about:

Call quality on flaky networks. A lawyer on Wi-Fi, a user on 3G in a Tier-2 city. We layer adaptive bitrate + reconnect-on-drop into the client.
Lawful recording (where required). Some calls must be recorded for compliance. Recording is server-side, not client-side, with explicit consent UI before the call starts.
Billing precision. Charges are per-minute, but the user expects to pay for the actual duration on their screen, not what the server logs. We reconcile both client and server timestamps and bill on the lower of the two.

Scheduled appointments are simpler: a calendar UI, time-zone-aware booking, automatic reminder notifications, a join-call button that becomes active 5 minutes before start time.

Course delivery

Our course module is a custom build, not a Moodle wrapper. Why: we needed to deeply integrate course completion with role progression ("complete this course to unlock the volunteer-lawyer application") and with the Advisor Hub ("after this course, book a 15-min consultation with the author").

Video is hosted on AWS S3 + CloudFront with signed URLs (24h expiry) so course content can't be hot-linked. Video progress is tracked at 5-second granularity for resume-where-you-left-off.

The forum and journals

The forum is a standard threaded structure (post, comment, reply) with role-aware moderation. Journals are long-form articles authored by senior lawyers with peer review; we built a lightweight "editor + reviewer + publish" workflow.

Both surface as separate screens in the app but share a unified search index, so a query like "contract breach" returns courses, forum threads, and journal articles together.

The admin panel

The admin panel has the longest changelog of any screen we've built. Operations live here: payout reconciliation, dispute resolution, user verification, course approval, journal publication, community moderation escalation, analytics. We built it as a Next.js app with role-based section visibility — every admin sees only the modules their role allows.

Stack summary

Mobile: Flutter (iOS + Android)
Web: Next.js (course web client + admin)
Backend: Node.js microservices + PostgreSQL
Real-time: WebSockets (signaling, chat, presence) + WebRTC (audio)
Background jobs: RabbitMQ (course reminders, payout batches, appointment notifications)
Architecture: Microservices (auth, courses, forum, advisor, payouts, notifications)
Design: Figma (7 persona maps, full design system) → Production
Deployment: AWS
Testing: Unit → Integration → Production

What we'd tell other LegalTech teams

Start in Figma. Stay in Figma. Map every persona before a single line of code. The cost of refactoring an architecture is 50x the cost of redrawing a flow.
Roles, not types. Don't hardcode if user.is_lawyer checks. Build a role + capability system from day one.
Recording is a compliance feature, not an engineering feature. Loop legal counsel in early; some jurisdictions require explicit signed consent before each recording.
Don't build your own video hosting. Use S3 + CloudFront + signed URLs. The bandwidth math will surprise you.
Build the admin panel as a first-class product. Operations teams use it 8 hours a day. If it's slow or messy, your operating costs balloon.

Building a LegalTech, EdTech, or multi-persona platform?

Whether it's legal, medical, financial, or any domain with regulated personas — the work is in the role mapping and the cross-persona flows, not the individual screens. If you're building one, Xenotix Labs has shipped this archetype across legal education, healthcare delivery, and edtech. Reach out at https://xenotixlabs.com.

From Figma to Flutter: Designing a System That Scales Across 30 Apps

Ujjawal Tyagi — Tue, 28 Apr 2026 07:38:46 +0000

We've shipped 30+ Flutter apps at Xenotix Labs across D2C commerce, real-time sports, edtech, healthtech, legaltech, marketplaces, and more. Each project starts the same way: Figma file, design system, component library, then code.

The non-obvious insight from doing this 30 times: the Figma design system and the Flutter component library should be the same artifact, conceptually. Tokens, components, layouts, type ramps — designed once, expressed in both Figma and Dart, kept in sync mechanically. When they drift, your designers and engineers stop trusting each other, and "Figma to production" becomes a punch line.

Here's the workflow we've converged on.

The single source of truth: design tokens

Design tokens are the atomic units. Colors, type sizes, spacing, radii, elevations, motion durations. We define them once in a JSON-like format and generate both the Figma library and the Flutter ThemeData from that single file.

{
  "color": {
    "primary": { "value": "#3F51FF" },
    "surface": { "value": "#FFFFFF" },
    ...
  },
  "space": {
    "xs": { "value": 4 },
    "sm": { "value": 8 },
    ...
  },
  "radius": {
    "card": { "value": 12 },
    ...
  }
}

A build script generates a Flutter tokens.dart file with strongly-typed constants. Designers import the same JSON into Figma via the Tokens Studio plugin. When a designer adjusts color.primary, both Figma and the Flutter app pick up the change automatically.

With this in place, there is no gap between "the design says" and "the app implements". They can't disagree. They share a parent.

The component library

On top of tokens sit components. Buttons, inputs, cards, list items, modals, tab bars, snackbars. We build each component twice: once as a Figma component with variants and properties, once as a Flutter widget with named parameters that mirror those properties.

The Flutter widget always uses tokens, never raw values. padding: EdgeInsets.all(tokens.space.sm), never padding: EdgeInsets.all(8).

The layout primitives

Most projects re-implement the same layouts in slightly different ways: a screen with an app bar, a body, a primary action at the bottom. A modal sheet with a title, body, and dismiss button. A list page with a search bar and infinite scroll.

We pre-built these as Scaffold-style layout widgets in our internal package:

XScaffold(title, body, primaryAction)
XBottomSheet(title, body, dismissAction, confirmAction)
XListPage(searchBar, items, onLoadMore, emptyState)

New projects start at the layout level, not the widget level. A login screen is two widgets, not twenty.

The package structure

One shared package, multiple apps:

xenotix_design/
  lib/
    tokens/         (generated from JSON)
    components/     (XButton, XCard, XInput, ...)
    layouts/        (XScaffold, XListPage, ...)
    icons/          (custom icons + lucide passthroughs)
  test/
  pubspec.yaml

Every app pulls xenotix_design as a path or git dependency. Updates to the package propagate to every app on next pubspec update.

We version the package strictly. Breaking changes go in major versions. Minor versions add components or non-breaking improvements. Apps pin to a major version and update minor versions on their own cadence.

The handoff workflow

Figma to Flutter handoff is the friction point on most teams. Ours:

Designer designs in Figma using the shared library (built on shared tokens)
Designer publishes a Figma frame with notes (interaction states, copy, edge cases)
Engineer opens the frame, identifies which existing components are used, and which new ones are needed
If a new component is needed, designer + engineer co-design it in the shared library first, then both the Figma and Flutter implementations are updated
Engineer implements the screen by composing existing components

No handoff document. No "can you make this padding 14 instead of 16?" because padding is a token, and tokens are shared.

The design system as a Storybook

We maintain a Flutter implementation of the design system as a runnable Storybook app: every component, every variant, every state, on a single navigable surface. Designers can scroll through it on a phone. Engineers can show "yes, this exact button in this exact state already exists, here's how to use it."

Storybook also doubles as the regression-test surface. Visual snapshot tests on every component, run on every PR.

What we'd tell a team starting their first Flutter design system

Tokens first, components second. A component built without tokens is a tax you'll pay later.
One package, not three. Don't split tokens, components, and layouts into separate packages until you have a real reason. Premature splitting creates dependency-graph pain.
Storybook from week one. It's the fastest way to catch component drift.
Visual diff tests in CI. Catches "the button is 1 px taller in this PR" before a designer notices.
Don't customize per app. Resist the urge to fork the design system per project. Push customization through tokens (color overrides, spacing adjustments) rather than forking widgets.

Stack summary

Tokens: JSON, generated to Dart and synced to Figma via Tokens Studio
Component library: custom Flutter package
Layouts: custom Flutter package
Storybook: runnable Flutter app per package
Distribution: internal git monorepo, pinned versions per app
Tests: flutter_test + alchemist or golden_toolkit for visual snapshots

Building a multi-app product family?

One design system across many apps is the difference between a coherent brand and 30 disconnected products. If you're scaling across multiple apps and need them to feel like one product, Xenotix Labs has the playbook. Reach out at https://xenotixlabs.com.

Building a Real-Time Opinion-Trading Engine: An Anatomy

Ujjawal Tyagi — Tue, 28 Apr 2026 07:35:28 +0000

If you've used Probo or any "opinion trading" app during an IPL match, you know the experience: the next over hasn't even started and you're buying YES at ₹3 that India will hit a six. Three balls later, your YES is worth ₹7 because the bowler has just been hit for two boundaries. You sell. You make ₹4 in 90 seconds.

This is a real-time prediction market. Underneath the breezy UX is one of the harder engineering problems in consumer fintech. At Xenotix Labs we built the trading engine for Cricket Winner. Here's the architecture.

The model

A market is a binary question that will resolve to YES or NO at a specific moment. "Will India win the toss?". "Will Kohli score a fifty in this innings?". "Will the next ball be a wide?".

Users buy YES or NO contracts. Prices are in rupees and always sum to ₹10 (because exactly one side will pay out ₹10 on resolution). If YES is ₹7, NO is ₹3. As opinion shifts, prices move.

When the market resolves, holders of the winning side get ₹10 each. Holders of the losing side get ₹0.

What's hard

Order books are real-time. Every buy or sell shifts the price; clients need updates within ~200 ms.
Settlement is binary and final. When India wins the toss, every YES holder needs ₹10 in their wallet within seconds, deterministically.
Markets resolve fast. A "next ball" market opens for ~30 seconds. Tens of thousands of orders may flow through in that window.
Money is involved. No skipped writes. No double-payouts. No drift. Wallet ledgers must reconcile down to the paise.

The pipeline

Client → REST place_order → Order Service → Kafka (trades-topic, partitioned by market_id)
                                                               ↓
                                            Matching Engine consumer (one per partition)
                                                               ↓
                                            Order book updates + matched trades
                                                               ↓
                                            Postgres write + Wallet debit/credit
                                                               ↓
                                            Redis pub/sub for price updates
                                                               ↓
                                            WebSocket gateways → Clients

The key constraint: per-market ordering must be strict. If two orders arrive at the same millisecond, only one of them can match the standing best bid; the other goes into the book or matches the next best.

We enforce this by partitioning Kafka by market_id, with one matching-engine consumer per partition. Within a partition, Kafka guarantees total ordering, so the matching engine processes orders one at a time, deterministically.

Why one matching engine per market

A matching engine is a state machine: order book in, trades out. If two engines act on the same market simultaneously, you get races. So we run one engine per market — single-threaded, in-process, with the order book held entirely in memory.

This sounds risky. "In memory" implies "lost on restart." The mitigation: every event is durably written to Kafka before the engine processes it. On restart, the engine replays all events from the beginning of the partition (or from a snapshot) and reconstructs the order book exactly.

We also snapshot the order book every 30 seconds to a Postgres order_book_snapshots table to bound replay time.

The wallet integration

Every trade involves two wallets: the buyer's (debited) and the seller's (credited). Both must update atomically.

We never call the wallet service synchronously from the matching engine. Instead, the engine emits a trade-executed event to another Kafka topic, and a wallet-update worker consumes those events and applies them as immutable rows to the wallet ledger (see our other post on why wallets are ledgers).

If the wallet update fails, the trade row is marked pending_settlement. A reconciliation worker retries every minute until success or hard failure. We've never lost money this way.

Settlement

When a market resolves (the official source says "India won the toss"), an admin endpoint marks the market as settled with the outcome. A settlement worker reads the order book + position table, generates one payout row per holder, and pushes the payouts through the same wallet-update pipeline.

Settlement is also idempotent: every payout is keyed by (market_id, user_id), so reruns don't double-pay.

The prices

Prices in this model are derived from the order book. The "current price" of YES is the midpoint of the best bid and best ask in the YES order book. As the book shifts, the price shifts.

We push price updates to clients via WebSocket every time the midpoint changes (deduped to ~10 Hz max, to avoid flooding mobile clients on volatile markets).

What's hard about real-time UX

The trading screen has to feel instant. The user taps "Buy YES at ₹7" and the price was ₹7 when they tapped. By the time the request reaches the server, it might be ₹7.50.

We handle this with limit orders + slippage protection. The user's request includes the price they saw. If the actual matched price exceeds it by more than the user's chosen slippage tolerance (default 5%), the order is rejected and the user is shown the new price. They re-confirm or back off.

This is how real exchanges handle the same problem. It's table stakes for fairness.

What we'd do differently

Snapshot more aggressively. 30 seconds is fine; 5 seconds is better. Replay time matters during incident recovery.
Use a separate Kafka cluster for the trade pipeline. Don't share with general application events. Trade volume is bursty and you don't want it competing for broker resources during match days.
Pre-warm matching engines for upcoming markets. When a market opens 30 seconds before tipoff, the engine should already be ready, not cold-starting.
Build a dedicated reconciliation dashboard from day one. When something goes wrong, you need a UI to see exactly which trades didn't settle, why, and a single-click "retry" button.

Stack summary

Mobile: Flutter
Web: Next.js
API gateway: Node.js
Matching engine: Node.js single-threaded worker per market partition
Event bus: Kafka, partitioned by market_id
Real-time: WebSockets + Redis pub/sub
Wallet: PostgreSQL ledger
Snapshots / reconciliation: PostgreSQL
Deployment: AWS MSK + ECS

Building a prediction market or trading product?

Real-time markets are unforgiving — every drift between client price, server price, and settlement value erodes trust. If you're building one, Xenotix Labs has shipped the full stack from Flutter UX to Kafka matching engine to settlement reconciliation. Reach out at https://xenotixlabs.com.

AWS Deployment Pipeline for Indian Startups: Our GitHub Actions + ECS Fargate Setup

Ujjawal Tyagi — Tue, 28 Apr 2026 07:34:54 +0000

We deploy 30+ products from one CI/CD playbook at Xenotix Labs (https://www.xenotixlabs.com). Indian startups—DPDPA-compliant, cost-efficient, fast-rollback. Here's the exact stack.

The pipeline

GitHub Actions for CI. Docker for packaging. AWS ECS Fargate for runtime. RDS Postgres for data. CloudFront + S3 for static. Sentry for errors. UptimeRobot for pings. That's it. We deliberately skip Kubernetes for startups under 10K MRR—the operational overhead doesn't pay off.

Branch strategy

main = production, develop = staging, feature branches = preview environments. Every PR gets a unique preview URL on a Cloudflare Pages-style serverless deployment of the frontend, plus a dedicated ECS task definition for the backend. Reviewers click the URL, test, approve. No "works on my machine" debates.

The Actions workflow

Four steps. (1) Lint and type-check on PR. (2) Run Playwright tests against the preview environment. (3) Build Docker image, push to ECR with git SHA + branch tag. (4) Update ECS service with the new image tag, wait for healthy targets, drain old ones.

Rollback in 30 seconds

The single-click rollback button in our internal dashboard re-deploys the previous git SHA's Docker image to ECS. We've used it twice in the last year, both times because of a third-party API change that broke our integration. 28 seconds from button-click to traffic on old version.

DPDPA compliance

India's data protection law requires data localization for sensitive PII. We use ap-south-1 (Mumbai) for all customer data. Backups stay in-region. Logs that touch PII are redacted at write-time, not read-time. Encryption at rest via KMS, encryption in transit via TLS 1.3 enforced.

Secrets management

GitHub Actions secrets for build-time, AWS Secrets Manager for runtime. Never .env files in repo, never hardcoded API keys. Quarterly rotation enforced via a cron that creates a PR with rotated values.

Cost optimization

Fargate Spot for non-critical workloads (cron jobs, async workers) saves ~50%. RDS reserved instances for the primary DB. CloudFront for static assets cuts S3 GET egress 90%. Total infra cost for a typical Veda Milk-scale product: under $300/month for the first 6 months.

Apps we ship this way

Veda Milk (D2C dairy subscription, Country Delight clone), Cricket Winner (real-time cricket on Kafka + WebSockets), Legal Owl (LegalTech super-app with 7 user personas), ClaimsMitra (insurance survey platform with 114+ REST APIs), Growara (AI WhatsApp automation), 7S Samiti (offline-first AI tutor for rural India). 30+ products shipped, same playbook.

Hiring us

If you are a founder shipping production infrastructure on AWS without DevOps headcount, we'd love to talk. Visit https://www.xenotixlabs.com or email leadgeneration@xenotix.co.in.

Subscription Pause Logic Is a Week of Work. Here's How to Get It Right.

Ujjawal Tyagi — Tue, 28 Apr 2026 07:33:23 +0000

The hardest feature in any subscription product isn't subscribing. It's pausing.

A customer wants to pause her milk delivery from the 12th to the 20th except on the 14th, because that's her son's birthday and she needs extra paneer. Resume regular delivery on the 21st. Skip Sundays as always. Pause again from the 28th to the 5th of next month for a vacation. While paused, don't bill. While paused for vacation, don't even count the days against her loyalty streak. When she resumes, push her renewal date forward by exactly the number of days paused.

The UI is three taps. The backend is a week of work. At Xenotix Labs we've shipped this engine for milk delivery (Veda Milk), subscription marketplaces (Prepe), snack-box subscriptions (Swaadm), and more. Here's the architecture pattern we keep reaching for.

What "pause" actually means

The naive model: a subscriptions table with a status column that goes active, paused, cancelled. Then a nightly job iterates active subscriptions and generates orders. Easy.

The real model: a subscription has a recurring schedule (every Mon/Wed/Fri, every day except Sunday, every weekend, the 1st and 15th of each month) AND a list of exceptions (skip Aug 14, skip Aug 12-20, skip Aug 28 onwards). The next delivery date is derived from both.

Generating orders becomes: for each active subscription, compute the schedule for tomorrow, check if tomorrow is an exception, generate an order if not.

The schema

subscriptions
  id, user_id, product_id, plan_id
  recurrence_rule  (rrule string or structured: days_of_week, frequency, etc.)
  start_date, end_date
  status           (active, cancelled)
  ...

subscription_exceptions
  subscription_id
  exception_type   (skip, deliver_extra, change_quantity)
  date_or_range    (single date or date range)
  reason           (vacation, special_request, system_pause, payment_failure, ...)
  created_at, created_by, metadata

Notice: there's no paused status on the subscription. "Pause from Aug 12 to Aug 20" is just an exception of type = skip over that date range. "Cancel" is the only state change to the subscription itself.

This sounds like overkill. It's not. Once you model pauses as exceptions, every customer-support tool, every analytics question, and every backfill becomes trivial.

Generating the order schedule

For any future date D, the question "will this subscription generate an order on D?" reduces to:

Is D between start_date and end_date (or no end_date)?
Does D match the recurrence_rule?
Is D covered by any subscription_exception of type skip?
If yes to (1) and (2) and no to (3), generate an order.

We encode this as a pure function: would_generate_order(subscription, exceptions, date) -> boolean. Pure, testable, has 200+ unit tests covering edge cases.

The customer-support superpower

When a customer calls saying "why didn't I get my milk on Aug 14?", support runs the function for that date with the customer's actual data:

would_generate_order(subscription_id=123, date='2026-08-14')
=> false (reason: matched exception E45 'vacation skip Aug 12-20')

The support agent sees exactly why, with full provenance. No mystery. No "let me escalate to engineering".

The vacation pause

"Pause my subscription for a week" creates one subscription_exception of type skip with the date range and reason vacation. Done. The recurrence rule is unchanged.

When the customer un-pauses early ("actually I'm back, please resume tomorrow"), we shorten the exception's date range. The recurrence rule still hasn't changed. The subscription's status is still active. The schedule for the next 30 days re-computes correctly.

The renewal-date adjustment

Many subscriptions are billed monthly. If a customer pauses for 7 days mid-month, you may want to push their next billing date forward by 7 days as a gesture. This is its own concern, separate from the schedule.

We track paused_days_credited on the subscription. Each skip exception with reason = 'vacation' increments the counter. The renewal worker reads the counter and pushes the renewal date forward when generating the next billing cycle.

Keeping this counter separate from the schedule means the billing logic stays simple, and the schedule logic stays simple. You can debug each independently.

The system-initiated pause

Not all pauses are voluntary. If a customer's payment fails, we may auto-pause until they update their card. This is also just an exception with reason = 'payment_failure'. When the payment succeeds, the worker shortens or removes the exception.

Differentiating system pauses from customer pauses by reason lets us:

Show different UI to the customer ("please update your card" vs. "on vacation")
Avoid double-counting payment-failure days as vacation credits
Run analytics on involuntary churn

What we'd tell our past selves

Model schedule + exceptions, not status transitions. Resist the urge to add a paused boolean. It looks simpler; it isn't.
Make would_generate_order a pure function. Test it exhaustively. It's the heart of the system.
Tag every exception with a reason. "Skip" is not enough; you need to know why later.
Don't auto-cancel on long pauses. Customers come back; cancellation churn is forever. If a customer hasn't unpaused in 90 days, send a reminder, don't cancel.
Show the customer their next 4 dates, computed in real time. Not the recurrence rule. The actual dates. This is the single most important UX element of a subscription product — the customer needs to know when their next delivery is.

Building a subscription product?

Whether it's milk, meals, content, or services — subscription commerce has dozens of these subtleties that compound over 12 months. If you're building one, Xenotix Labs has the scars from shipping subscription engines across multiple verticals. Reach out at https://xenotixlabs.com.

Why Every D2C Wallet Should Be a Ledger, Not a Counter

Ujjawal Tyagi — Tue, 28 Apr 2026 07:30:54 +0000

Friday post-mortem: when we deleted 30,000 customer wallets by accident.

Then realized we didn't.

Because we'd built the wallet as a ledger, not a counter.

This is one of those engineering choices that feels overcautious in week one and saves your business in month nine. At Xenotix Labs we've shipped wallet systems for D2C dairy commerce (Veda Milk), subscription marketplaces (Prepe), service marketplaces (Cremaster, Housecare), insurance survey payouts (ClaimsMitra), and crypto MLM (BullBot). Different industries, same wallet architecture pattern. Here's why.

The two ways to model a wallet

The counter approach. A users table has a wallet_balance column. Every credit and debit updates the column with UPDATE users SET wallet_balance = wallet_balance + ? WHERE id = ?. Simple, fast, easy to query.

The ledger approach. A wallet_ledger table records every credit and debit as an immutable row. The user's "balance" is computed at read time as SUM(amount) over their ledger entries. Slightly more storage, slightly more compute on read, but with a critical property: history is preserved.

Most teams ship the counter approach because it looks simpler. Then they spend the next two years answering customer-support tickets like "why is my balance off by ₹12?" with no way to answer.

What the ledger gives you

Auditability. Every change is a row with a timestamp, a reason code (signup_credit, order_debit, refund, manual_adjustment), an actor (user, system, admin), and a reference (which order, which subscription, which support ticket). When a customer disputes a balance, you have the receipts.

Reversibility. When a bug double-charges customers, you don't fix it by manually editing balances. You insert reverse entries with reason_code = 'reversal_of_X' linking to the bad rows. The reversal itself is now an audit-trail entry. You can prove what happened to anyone who asks.

Re-derivability. If your wallet_balance cache (yes, you can still cache the computed balance) gets corrupted by a bad migration, you re-derive it from the ledger in one query. We've done this in production. It's a non-event when the ledger exists.

Concurrency safety. Two simultaneous debits from the same user can't race when each is its own row. With a counter, you're relying on database-level locking which is fragile across multiple services.

The schema

Here's a stripped-down version of what we ship:

wallet_ledger
  id              (uuid, primary key)
  user_id         (foreign key)
  amount          (integer, in paise; positive = credit, negative = debit)
  reason_code     (enum: signup_credit, order_debit, refund, ...)
  reference_type  (string: 'order', 'subscription', 'support_ticket', ...)
  reference_id    (uuid, points at the entity that caused this entry)
  idempotency_key (uuid, prevents duplicate inserts)
  created_at      (timestamp)
  metadata        (jsonb, free-form for analytics)

No updated_at. Rows are never updated, only inserted.

The balance query

SELECT COALESCE(SUM(amount), 0) AS balance_in_paise
FROM wallet_ledger
WHERE user_id = $1;

Fast on indexed user_id even with millions of rows. If it gets slow at scale, materialize a wallet_balance_cache table that stores the computed balance per user and gets updated by an after-insert trigger. The ledger remains the source of truth; the cache is just an optimization.

Idempotency, always

Every wallet write must be idempotent. Networks fail. Workers retry. If the same idempotency_key is inserted twice, the second insert is a no-op (we use INSERT ... ON CONFLICT (idempotency_key) DO NOTHING).

This costs one indexed column. It saves you from being the engineer at 2 a.m. who has to figure out whether the customer was double-charged.

The transactional wrapper

Wallet debits never live alone. They're paired with the operation they pay for: an order placement, a subscription renewal, a service booking. We always wrap both in a single Postgres transaction:

BEGIN;
INSERT INTO orders (...) VALUES (...);
INSERT INTO wallet_ledger (..., amount = -order.amount, ...);
COMMIT;

If either insert fails, both roll back. There's no state where the order exists but the wallet wasn't charged, or vice versa.

For cross-service flows (order service writes the order; wallet service writes the ledger), we use the outbox pattern: the order service writes the order + an outbox row in the same transaction, and a worker picks up the outbox row and tells the wallet service to debit. Eventually consistent, never inconsistent.

Refunds

A refund is a positive ledger entry with reason_code = 'refund' and reference_id pointing at the original debit. We never "reverse" a debit by editing it. We compensate with a new entry. The customer's balance updates correctly and the audit trail shows exactly what happened.

Reporting

With a ledger, financial reporting is trivial. "How much did we credit users last month?" is SUM(amount) WHERE amount > 0 AND reason_code = 'signup_credit' AND created_at IN (...). Counter-based wallets can't answer that without a separate analytics system you forgot to build.

Lessons from production

Use an integer paise/cent column, never a float. Floating-point arithmetic in money columns is how you get ₹0.0000001 errors that compound.
Snapshot balances daily. Even with a fast SUM query, a daily wallet_balance_snapshot table lets you do historical analytics ("what was the balance on March 1?") without scanning the whole ledger.
Rate-limit manual_adjustment writes. This is the only way for non-systematic balance changes to enter the ledger. Audit it heavily.
Don't delete ledger entries, ever. If a row was inserted by mistake, insert a compensating reversal. Deletion breaks the audit trail forever.

Building a wallet, points system, or money-handling product?

Whether it's subscription wallets, marketplace earnings, escrow, points, or refunds, Xenotix Labs has shipped ledgers that survive real customer load and real edge cases. Reach out at https://xenotixlabs.com.

Building a B2B Marketplace at the Speed of a B2C App

Ujjawal Tyagi — Tue, 28 Apr 2026 07:28:51 +0000

B2B marketplaces have a reputation: clunky UX, multi-day onboarding, KYC stuck in PDFs, dashboards that look like 2005, and a UX gulf between the buyer side and the seller side. Most of that is not because B2B is harder — it's because B2B teams build for the procurement officer's checklist instead of the user's experience.

At Xenotix Labs we've shipped marketplaces across home services (Cremaster, Housecare Solutions), insurance surveys (ClaimsMitra), franchise discovery (Eazybizzy), property listings (Property Kona, Go Society), wedding planning (My Shaadi Store), and bike parts (Axmile). Some are pure B2C, some pure B2B, and some are B2B2C. Here's what we've learned about giving a B2B marketplace the feel of a B2C app without losing what makes B2B work.

The four expectations B2C has trained users to demand

Whether your user is a procurement officer at a 500-person company or a homeowner ordering a plumber, they bring four expectations from B2C apps:

Search returns results in under 200 ms. No spinner, no "please wait while we fetch".
Onboarding is under 90 seconds. Tap, OTP, in.
Status updates are real-time. I see what's happening as it happens, not on the next page refresh.
The app works on mobile. Not "works on mobile". Works first on mobile.

Most B2B marketplaces fail at all four. The teams that meet all four win the segment.

How we structure a B2B marketplace

A B2B marketplace usually has three users with very different needs:

Buyer (browses, requests quotes, places orders, reviews)
Seller / Service Provider (lists, accepts, fulfills, gets paid)
Admin (onboarding, dispute resolution, payouts, KYC, analytics)

We build all three as separate Flutter or Next.js apps that talk to a shared microservices backend. The buyer app is mobile-first. The seller app is mobile-first (sellers are usually on a phone in the field). The admin panel is web-first (operations teams live in dashboards).

Never the same UI. Never one app with role toggles. Each persona deserves a UI built for them.

The sub-second search

The procurement officer's first impression of your marketplace is your search bar. If it lags, you lose.

Our stack: Postgres for canonical data, an indexed search service for query latency, Redis for caching popular query results, and a CDN-fronted Next.js or Flutter client that prefetches likely-next searches.

For very large catalogs, we add typeahead with debounced 150ms requests, server-side typo tolerance, and synonym expansion (the buyer searching "plumber" should also find listings tagged "sanitary").

Onboarding under 90 seconds

The biggest mistake B2B onboarding makes: asking for everything upfront. GST number, PAN, bank details, ID proof, business proof, address proof, three references, and a verification call — all before the user can see a single listing.

Fix: progressive KYC. The buyer signs up with phone + OTP and gets immediate access to browse and shortlist. Higher-trust actions (placing an order over a threshold, accepting payouts as a seller) trigger the next KYC step contextually, when the value of completing it is obvious to the user.

We also pre-fill what we can. PAN is usually inferable from GST. Address can be auto-detected. The user types fewer characters than they think.

Real-time everything (the parts that matter)

Not every screen needs to be real-time. The ones that do, religiously:

Order status — "out for delivery", "arrived", "completed" updates as they happen
Quote responses — when a seller accepts a quote, the buyer sees it instantly
Inventory levels — if a seller is running low, the buyer should know before placing an order
Pricing changes — if a seller updates pricing, the buyer's open carts reflect it (with a clear notice)

We use WebSockets backed by Redis pub/sub. Sellers are notified the same way. Both apps converge on the same state in under a second.

The seller side is harder than the buyer side

Most teams under-invest in the seller experience. That's a mistake. Sellers are a much smaller user base than buyers, but they generate the supply that the entire marketplace runs on. If the seller app is bad, supply dries up and the marketplace dies — no matter how good the buyer experience is.

The seller app has to be:

Fast on cheap phones (most field sellers use mid-range Androids)
Offline-tolerant (delivery boys, surveyors, and service providers have spotty networks)
Notification-rich without being annoying (a seller who misses a job loses revenue)
Built around the actual seller workflow, not a buyer workflow with seller "toggles"

We usually ship a separate Flutter app for sellers, with offline-first storage, geo-fenced check-ins, and a job-acceptance flow optimized for one-tap action.

The admin panel

Admin panels are where B2B marketplaces actually live or die. The operations team uses it 8 hours a day to onboard sellers, resolve disputes, manage payouts, run promotions, and answer support tickets. If it's slow or messy, the marketplace's operational cost balloons.

We build admin panels as Next.js apps with role-based access, audit logs on every write, server-side filtering and pagination (admin pages often display thousands of rows), and tight integration with our background-job system for batch operations.

Tech stack we keep reaching for

Mobile (buyer + seller): Flutter
Web buyer (when needed): Next.js (SSR for SEO)
Admin: Next.js
Backend: Node.js microservices + PostgreSQL
Background jobs: RabbitMQ for orchestration, cron for scheduled tasks
Real-time: WebSockets + Redis pub/sub
Search: Postgres FTS for small catalogs, dedicated search service for large ones
Storage: S3 + CloudFront for media
Deployment: AWS ECS, RDS, ElastiCache

Building a marketplace?

Whether B2B, B2C, or hybrid — the same engineering principles apply, with subtle adjustments per persona. If you're building one, Xenotix Labs has shipped marketplaces in plumbing, insurance, real estate, weddings, food delivery, plant nurseries, and more. Reach out at https://xenotixlabs.com.

Shipping AI WhatsApp Automation to Production: Lessons from Growara

Ujjawal Tyagi — Tue, 28 Apr 2026 07:26:29 +0000

Most AI-on-WhatsApp demos fall apart in production. The customer asks the same question three different ways. Sentiment shifts mid-conversation. The AI answers something it doesn't actually know — confidently and wrong.

Building Growara at Xenotix Labs — an AI-powered WhatsApp automation platform — taught us that you don't deploy an LLM to WhatsApp. You deploy a system that contains an LLM.

Here's the architecture we settled on after shipping to production for businesses handling 100k+ messages a month.

The system, not the model

A naive WhatsApp AI bot looks like this: send the message to the LLM, return whatever it says. Works for the first hundred messages. Then a customer asks "kya tum refund de doge?" and the LLM hallucinates a refund policy that doesn't exist.

The production system looks like this:

WhatsApp → Webhook
Intent Classifier (small fast model)
Knowledge Retrieval (vector store of business policies)
LLM with retrieved context
Confidence Check
Reply / Escalate to Human / Ask Clarifying Question

Each layer is doing one job, and the LLM is just one component — not the whole brain.

Layer 1: Intent classification before LLM

Every inbound message gets classified before it touches an LLM. Categories:

Transactional intent (refund, cancel, change address) → high-stakes path
Informational (store hours, return policy, product specs) → retrieval path
Conversational (greeting, smalltalk) → templated reply
Out-of-scope (medical, legal, anything unrelated) → polite decline

We use a small fine-tuned classifier model running locally — not the main LLM. Fast, cheap, deterministic. Don't pay LLM token costs for a binary decision.

Layer 2: Retrieval-augmented context

For informational intents, we never let the LLM "freestyle." We retrieve relevant content from a vector store of the business's actual policies, product catalog, FAQs, and shipping rules.

The retrieved chunks are passed into the LLM as context with a hard system prompt: "Answer ONLY using the retrieved context below. If the answer is not in the context, say you don't know and offer to escalate."

This is the difference between hallucinated refund policies and accurate ones.

Layer 3: Confidence scoring

Every LLM response goes through a second pass that scores confidence (does the response actually match the retrieved context?), sentiment (is the customer frustrated, happy, neutral?), and action commitment (does the response promise something the system can't actually do?).

If confidence is low, or the response promises an action we can't fulfill, we escalate to a human.

Layer 4: Hard escalation triggers

Some things never go to the LLM. Hard-coded triggers immediately route to a human:

Mentions of "complaint", "refund over [X]", "lawyer", "consumer court"
Sentiment sharply negative for 2+ messages in a row
Customer routed through AI 5+ times without resolution
Any payment, refund, or monetary commitment over a threshold

Better to over-escalate than to let an AI commit to a refund the business can't honor.

The infrastructure

The Meta WhatsApp Business API has its own rules — message templates for outbound, 24-hour customer-service window, opt-in management, rate limits per phone number.

Our stack:

Webhook receiver — Node.js handling Meta webhooks, signature verification, dedup
Message queue — RabbitMQ for inbound buffering and outbound rate limiting
AI orchestration — Node.js running classify → retrieve → LLM → confidence pipeline
Vector store — per-tenant knowledge bases (each business has its own)
Conversation store — PostgreSQL for canonical history + audit log
Human handoff — Next.js dashboard with pre-drafted AI responses for human review
Template manager — for managing Meta-approved message templates

Cost guardrails

LLMs cost per token. Without ceilings, one chatty user with a long conversation costs more than they're worth.

Our rules:

Per-conversation token budget (10k input + 2k output max)
Per-user daily cap (50k tokens/day max per phone)
Per-tenant monthly cap (configurable; alerts at 80%)
Cheaper models for non-critical paths (classification, summarization use smaller models)

When a budget hits, gracefully degrade: handoff to human or send a templated "we'll get back to you".

Evals before deployment

Every prompt change, every retrieval tweak, every model swap goes through an evaluation suite of ~500 representative conversations. Eval scores tracked in CI like test coverage — a regression below threshold blocks the merge.

Without evals, "improvements" silently break edge cases. With evals, you ship with confidence.

What we'd do differently

Build evals on day one. Reverse-engineering an eval suite after 6 months of production is brutal.
Don't trust LLM JSON output. Use a smaller model or schema validator before acting on it.
Pre-translate, then prompt. For multilingual (Hindi/English/Tamil), translating to English before the main LLM was more reliable than mixed-script prompts.
Log everything. Every classification, every retrieved chunk, every score, every prompt version. When something goes wrong in production, you'll need all of it.

Building AI-powered customer engagement?

Whether it's WhatsApp, in-app chat, voice, or email — production AI is a discipline. The model is 10% of the work; the rest is the system around it. If you're building in this space, Xenotix Labs has shipped AI customer-engagement products that survive real customer load. Reach out at https://xenotixlabs.com.

Smart Contracts in Production: What We Learned Building a Tokenized Loyalty Platform

Ujjawal Tyagi — Tue, 28 Apr 2026 07:23:46 +0000

Most blockchain projects we see in India are theatre. Tokens with no utility, NFTs that nobody actually owns, smart contracts copy-pasted from a tutorial. When a client at Xenotix Labs (https://www.xenotixlabs.com) asked us to build a tokenized loyalty platform for a real B2C brand, we had to make blockchain actually pay for itself. Here is what worked and what didn't.

The constraints

The brand wanted: customers earn loyalty tokens for purchases, can spend tokens on cashback or merchandise, can transfer tokens peer-to-peer, and (this was the hard one) can NEVER lose tokens because of a wallet failure or seed phrase loss. Most consumers in India don't understand wallets. They just want the points to work like points.

Custodial-first, with optional self-custody

We built it custodial-first. The platform owns the wallets, the customer signs in with email + OTP, and the tokens live on a private ERC-20 deployment on Polygon. Customers can later "graduate" their wallet to self-custody if they want to, but 99% don't bother—which is fine. We use OpenZeppelin's MinimalForwarder for gasless transactions so customers never see gas fees.

This got pushback from blockchain purists ("not your keys, not your coins"). We don't care. Mainstream adoption requires custodial UX. The blockchain is an implementation detail.

The contract architecture

Three contracts. (1) ERC-20 token contract with mint/burn limited to the platform multisig. (2) Loyalty engine contract that records earn and burn events with merchant ID and category, so we can do reporting on-chain. (3) P2P transfer contract with built-in compliance hooks (we throttle large transfers and require KYC above a threshold).

We deliberately did NOT make the contracts upgradeable on day one. Upgradeable proxies introduce admin keys that are basically a backdoor; security auditors hate them. Instead we wrote a migration-via-snapshot pattern: when we need to upgrade, we deploy new contracts, snapshot the old state, and bulk-mint into the new contract. Manual, but auditable.

Off-chain state matters more than on-chain

Here's the unglamorous truth: 90% of our backend code is off-chain. The on-chain work is the source of truth for token balances and transfers, but everything else (merchant catalogs, redemption rules, fraud detection, customer support) lives in PostgreSQL. The blockchain is the ledger. The database is the application.

We sync between the two using an indexer (we use Goldsky on top of Polygon RPC) and a reconciliation cron that flags any drift.

What we'd do differently

We'd skip Solidity for v1 and use a programmable database with cryptographic audit logs. The marginal value of public chain immutability for a closed-loop loyalty program is low. We learned this 4 months in. The next iteration of the product is moving to that direction.

Other apps we've shipped at Xenotix Labs

Veda Milk (D2C dairy subscription, Country Delight clone), Cricket Winner (real-time cricket on Kafka + WebSockets), Legal Owl (LegalTech super-app with 7 user personas and live lawyer calls), ClaimsMitra (insurance survey platform with 114+ REST APIs), Growara (AI WhatsApp automation), 7S Samiti (offline-first AI tutor for rural India). Stack: Flutter, Next.js, Node.js on AWS plus blockchain integrations when actually needed. 30+ products shipped.

Hiring us

If you are building a loyalty product, a tokenized rewards platform, or something that needs blockchain plumbing without blockchain theatre, we would love to talk. Visit https://www.xenotixlabs.com or email leadgeneration@xenotix.co.in.