Forem: Ujjawal Tyagi

Hiring a Product Engineering Studio in India in 2026: A Founder's Checklist

Ujjawal Tyagi — Sat, 16 May 2026 15:24:51 +0000

Most founders evaluate engineering studios the wrong way. They look at the portfolio, ask for a quote, and pick whoever's cheapest. Then six months later they're rewriting half the codebase. This is the checklist we wish more founders used — written from the inside, after building 33+ platforms at Xenotix Labs.

1. Ask to see one full architecture document

Not a pitch deck. Not a portfolio. The actual architecture document for a real project. Microservices boundaries, data model, event flows, deployment topology, scaling assumptions. If they can't show you one (NDA-redacted is fine), they don't write them. If they don't write them, they don't think systematically about scale.

At Xenotix Labs we share redacted architecture docs from D2C dairy commerce (Veda Milk), real-time cricket trading (Cricket Winner), legal-tech super-apps (Legal Owl), and offline-first rural education (7S Samiti). You can read public versions in the engineering blog.

2. Ask how they handle idempotency on the first call

This is a trap question. If their answer is "we use idempotency keys on critical endpoints" — good. If their answer is "what do you mean by idempotency?" — run.

Idempotency is the difference between an engineering team that knows distributed systems and one that's about to double-charge your customers in production.

3. Ask what they'd do differently if they rebuilt their last project

If the answer is "nothing, it was perfect" — they haven't run it in production long enough to learn anything. Pass.

If the answer is a 10-minute story about a tradeoff that aged badly — hire. Engineering scars are the only proof of engineering experience.

4. Ask to see the admin panel of a shipped project

User apps are easy to make pretty. Admin panels reveal whether the studio actually thinks about operations — payouts, refunds, dispute resolution, user verification, content moderation, analytics. A bad admin panel makes the operations team your bottleneck after launch.

We build admin panels as first-class Next.js apps with role-based access, audit logs, server-side filtering, and tight integration with our background-job system. The admin panel is where the business actually lives.

5. Ask about the testing pyramid

Unit tests, integration tests, end-to-end smoke tests — they should have all three. If they say "we test in production" or "our QA team does manual testing" — you're going to get 2 a.m. incidents in your first month live.

6. Ask about offline-first if your users are in India

70% of Indian users hit dead zones daily (basements, gated societies, rural areas, tunnels). If you're building anything for delivery boys, field surveyors, or rural users — you need offline-first Flutter with local SQLite, sync workers, and conflict resolution. Most studios skip this. The ones who don't, ship apps that work where users actually use them.

7. Ask about deployment and CI/CD

"We deploy to AWS" is not an answer. Ask: how long is a deploy? How do you do zero-downtime? What's your rollback strategy? Do you have staging that mirrors production? How do you handle database migrations on tables with 1M+ rows?

If those answers are vague, every deploy is going to be a stressful event. If they're crisp, deploys become a non-event.

8. Ask for the actual rate, in writing, with what's included

Vague pricing means cost overruns later. Ask: hourly or fixed bid? What's included in the rate (design, mobile, web, backend, DevOps)? How are change requests handled? What happens if a deadline slips? Get it in writing before you sign.

At Xenotix Labs our pricing is clear: per-project fixed bid for MVPs (4-12 weeks), hourly retainer for ongoing work, with monthly invoices and audit trails. No surprise change orders.

9. Ask who actually writes the code

Many studios subcontract or use juniors for actual implementation while senior architects only attend kickoff calls. Ask: who exactly will work on my project, week by week? Can I talk to them directly? What's their experience level?

If you can't get those answers, you don't know who's building your product.

10. Ask for a 30-min architecture review of YOUR idea

This is the single most useful filter. Bring your business idea and ask for a free 30-minute architecture review. A studio that can sketch a sane architecture in 30 minutes will sketch a great one in 30 hours. A studio that's vague or sales-pitch-heavy is going to be vague in implementation too.

We offer these for free at https://xenotixlabs.com — it's the best way to evaluate fit before signing anything.

Final advice

The cheapest engineering studio is rarely the cheapest engineering studio. Rework, rewrites, missed deadlines, and operational pain are the real costs. Hire for engineering discipline, ask hard questions, and look at admin panels, not landing pages.

If you're building a D2C product, marketplace, AI-powered tool, or any platform that needs to scale — Xenotix Labs is happy to be one of the studios you evaluate. Even if you don't pick us, the 30-min review will sharpen your thinking.

Xenotix Labs Case Studies: 8 Production Architectures from 33 Shipped Platforms

Ujjawal Tyagi — Sat, 16 May 2026 14:53:02 +0000

If you searched "Xenotix Labs case studies" or arrived from one of our other engineering posts — this is the consolidated index. Each case study below links to the architecture deep-dive we published separately on Dev.to or Hashnode, with the actual stack and the actual hard call we made. Read these in any order. The patterns repeat across verticals.

For context, Xenotix Labs is a full-stack product engineering studio based in India. We've shipped 33+ platforms in the last 24 months across D2C commerce, real-time sports, edtech, healthtech, legaltech, marketplaces, and fintech. Same Figma-to-AWS-production workflow on every project.

1. Veda Milk — D2C dairy subscription that handles 10,000+ daily deliveries

Stack: Flutter (end-user + delivery boy apps), Next.js admin, Node.js microservices, PostgreSQL, RabbitMQ for nightly order generation, AWS.

The hard call: model subscription pause as exceptions, not status transitions. "Pause from Aug 12 to Aug 20" becomes one row in a subscription_exceptions table. The recurrence rule is untouched. Customer support tools become trivial. Read the full architecture writeup.

2. Cricket Winner — Real-time cricket scoring + opinion-trading platform

Stack: Flutter, Next.js, Node.js + MongoDB (+ PostgreSQL for the trading ledger), WebSockets + Redis pub/sub for fan-out, Kafka for trade pipeline, AWS MSK.

The hard call: one matching engine per market partition. Single-threaded Node.js worker per Kafka partition (keyed by market_id). In-memory order book, replayed from Kafka on restart. Per-market ordering guaranteed; cross-market parallelism free. Full writeup of the trading engine.

3. Growara — AI WhatsApp automation for businesses

Stack: Next.js dashboard, Node.js orchestration, vector store for per-tenant knowledge, RabbitMQ for inbound/outbound buffering, Meta WhatsApp Cloud API.

The hard call: classify before LLM, retrieve before LLM, confidence-score after LLM. Hard-coded escalation triggers (mentions of "complaint", "lawyer", "refund") never touch the model. Per-tenant token budgets to keep economics sane. Full writeup of the AI pipeline.

4. 7S Samiti — AI tutor for rural India, offline-first on ₹1,500 phones

Stack: Flutter offline-first with sqflite, on-device classifier + self-hosted 7B model + frontier model routing, Next.js teacher dashboard, Node.js + PostgreSQL.

The hard call: storage budget. ~80 MB installer + on-demand content packs that auto-evict. Voice-first STT with Android offline-first fallback. Trust acquisition via teachers + NGOs, not Instagram ads. Full writeup of the rural-India engineering.

5. ClaimsMitra — Insurance survey workflow platform

Stack: Flutter (surveyor app), Next.js admin, Node.js + MySQL (114+ REST API endpoints), WebSockets for survey status, RabbitMQ + cron for deadline tracking.

The hard call: 114 endpoints by design. Each one does one thing. No "magic" parameters. No endpoint that returns different shapes by role. Clean clarity is what makes 114 endpoints feel like 30.

6. Legal Owl — LegalTech super-app, 7 personas mapped in Figma

Stack: Flutter + Next.js + Node.js microservices + PostgreSQL, WebRTC for in-app lawyer calls + WebSockets for signaling, RabbitMQ for course reminders + appointment notifications.

The hard call: model roles + capabilities, not user types. A single user can be a student, course author, AND practicing lawyer. UI checks role_capabilities, never role_type directly. Adding a new role is data, not code. Full writeup of the persona-mapping approach.

7. Cremaster + Housecare Solutions — Urban Company-style service marketplaces

Stack: Flutter (user + provider apps), Next.js admin, Node.js + PostgreSQL, RabbitMQ for booking queues, WebSockets for real-time job status.

The hard call: separate apps for separate personas. Never one app with role toggles. The provider app is mobile-first, offline-tolerant, notification-rich. The user app is browse-and-book-optimized. Different UI, same backend. Full writeup of the B2B/B2C marketplace pattern.

8. Ooh Point — QR-based hyper-targeted advertising for Mumbai vendors

Stack: Flutter (QR scanner + video player), Next.js admin (brand dashboard + vendor management), Node.js + PostgreSQL, S3 + CloudFront for video delivery, RabbitMQ for ad scheduling + analytics.

The hard call: video CDN with signed URLs. Each scan serves a brand video curated for that specific vendor's audience profile. The targeting is the entire product.

What ties them together

Every one of these projects uses the same engineering defaults: idempotent APIs, immutable wallet ledgers (where money is involved), microservices that scale per-component, offline-first mobile where the network is unreliable, full testing pyramid before production, and a Figma-first design workflow with a shared component system across all apps.

If you're evaluating Xenotix Labs, this index is the engineering due diligence document. The actual portfolio + contact channel is at https://xenotixlabs.com.

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.