The stack behind Maarga: Flutter, Next.js and NestJS.
We built a four-part pilgrimage platform — mobile app, admin panel, backend, and marketing site — as one connected system. Here is the exact architecture and why we chose it.
Maarga (मार्ग — "the path") is a spiritual pilgrimage platform: curated journeys to sacred sites across India, booked end to end. One engagement, four connected products — a Flutter mobile app for pilgrims, a Next.js admin panel for operators, a NestJS backend API, and a marketing site.
This is the architecture we chose and the reasoning behind each piece, so your team can steal the thinking rather than the shopping list.
Why four parts instead of one monolith
The users could not be more different. A 60-year-old pilgrim booking a Yotirlinga journey needs large text, three languages, and patience. An operations lead managing hotels, vehicles, and refunds needs density and speed. Forcing both into one interface produces two mediocre experiences.
The mobile app: Flutter
We chose Flutter for the pilgrim app for three reasons:
- One codebase, both stores — the audience splits across Android and iOS by region, and Flutter keeps feature parity honest
- Offline-first patterns — bookings must survive patchy connectivity on mountain roads; local persistence plus a sync queue handles it
- True native feel — GetX keeps state predictable at this scale without an rewrite-worthy abstraction layer
The app handles OTP login, Hindi and Marathi alongside English, voice search, Razorpay payments, rescheduling, and cancellations with real refund policies.
The backend: NestJS with a versioned REST API
NestJS gives us a structured, opinionated backend where a growing team can find things. The API is URI-versioned at /api/v1 — unglamorous, and exactly what you want when a payment webhook from 2024 still needs to resolve in 2027.
Around it: PostgreSQL on Neon with Drizzle ORM for type-safe queries, Redis with BullMQ for job queues (payment retries, notifications, document generation), Firebase Cloud Messaging for push, and Swagger/OpenAPI docs generated from the code itself.
The admin panel: Next.js 16
Operators live in this panel all day, so it earned the good chair: dashboard analytics with Recharts, availability and pricing calendars, logistics management for hotels and vehicles, refunds, reviews moderation, and an audit log for every consequential action.
Next.js server components keep the data-heavy screens fast without shipping megabytes of client JavaScript to a team that just needs tables that load.
The AI + human support system
Support runs as a hybrid: an AI assistant handles the predictable 70% — booking status, what to carry, itinerary questions — across WhatsApp and in-app chat, and escalates the rest to humans with full context attached. Pilgrims get answers in minutes; the support team spends their hours on the conversations that need judgment.
What we would do differently
Nothing structural. The honest regrets are scheduling: we would integrate push notifications and the refund-policy engine earlier, because every week those landed late, operations felt the gap.
If you are planning a platform with a consumer app and an operator side, the takeaway is simple: architect for the two audiences separately, connect them through one disciplined API, and give operations tooling the same craft as the customer-facing product.
An AI-first product studio in India shaping web, mobile, desktop, and AI products — from first idea to everyday growth.