Free delivery over ₹999 · Book a free eye test at your nearest store
The Vision360 platform

One system. Four experiences. Built to run an optical business end to end.

Customers shop online and in-app, stores fulfil and sell, and the brand runs the whole network — all on a single API and database. Here's how the pieces fit together.

The big picture

Four front-ends, one brain

Every surface talks to the same NestJS API over HTTPS with a signed token. The API is a modular monolith — one deployable service with clean internal boundaries — backed by Postgres and a Redis job queue.

Storefront
Customers
Browse, configure lenses, buy
OTP
Mobile app
Customers
The storefront, native
OTP
Store Console
Store staff
Fulfil orders, run the store
Staff login
Admin Console
Brand admins
Catalog, stores, payouts
Staff login
NestJS API
modular monolith · 25 modules · global guards · /api · Swagger at /docs
PostgreSQL
system of record · append-only ledgers
Redis · BullMQ
background jobs · notifications · OTP
How the modules relate

Orders is the hub; a few shared services do the heavy lifting

The backend is split into focused modules. Most are independent, but the commerce core leans on a handful of shared services. Reading the arrows tells you the whole story.

Cartcheckout converts toOrders
Ordersreserves & finalises stockInventory
Ordersapplies couponsMarketing
Ordersapplies member discountMembership
Paymentsmarks paid on webhookOrders
Returnsrestocks & refundsInventory + Payments
Analyticsreads low-stockInventory
Everythingqueues messages viaNotifications

Notifications is the shared outbound-message service everything queues through; Inventory, Marketing and Membership are shared services the order engine composes. Catalog, prescriptions, wishlist, reviews, CMS and more stand on their own.

A customer order, start to finish

Every order moves through one guarded lifecycle

Status is the engine. Each step is a checked transition that also moves money and stock in append-only ledgers — so the whole history is auditable.

1Created
cart → order, stock reserved
2Paid
gateway webhook confirms
3Processing
store accepts
4Ready
packed for dispatch
5Dispatched
reservation → sale, shipment
6Delivered
commission accrues
Returned / Cancelled— a refund restocks inventory and writes a commission reversal; a failed payment releases the stock reservation.
The signature flow

Buying prescription glasses, made simple

When a customer picks a frame, the lens configurator walks them through a guided build — and assembles the frame, lens and coatings as one linked group in the cart.

1
Lens type
Single vision, progressive, zero-power…
2
Package & coatings
Index/material + anti-glare, blue-cut
3
Prescription
Saved, entered, or submit later
4
Add to cart
Frame + lens + coatings, one group
Why the numbers can be trusted

Stock and money are append-only ledgers

Inventory is never an editable number. On-hand is the running sum of immutable movements per SKU per location — the same idea powers payments and store commissions, so every figure is reconstructable from history.

Inventory ledger · one SKU
receipt+100
reservation−2
sale−2
transfer_in+20
On-hand = Σ deltas116
Auditable
Every change is a row with a reason and a reference — you can replay the entire history.
Concurrency-safe
Reservations lock the SKU row, so two checkouts can't sell the same last unit.
Multi-location
The same SKU has independent balances at the warehouse and each store.
Who can do what

Five roles, scoped to their store

Access is role- and permission-based. Store staff only ever see their own store's data; the brand admin sees the whole network. The same rules guard every screen and every API call.

CustomerShop, save Rx, track orders & returns
Store staffFulfil orders, handle returns, CRM
Store ownerAll staff powers + store settings & inventory
WarehouseCentral stock, transfers, fulfilment
Brand adminEverything — catalog, stores, marketing, payouts
The shape of the data

Everything connects around customers, orders and stores

A simplified map of how the core records relate — the full schema spans ~38 models across catalog, inventory, payments, marketing, CRM and more.

CustomerplacesOrdercontainsOrder lines
OrderStore
fulfilled by (or warehouse)
Order lineSKU
a variant of a Product
Order linePrescription
for Rx lenses
OrderPayment
captured / refunded rows
StoreCommission
accrues → Payout
CustomerCart · Wishlist · Address
profile & shopping
Built with

A modern, type-safe stack

NestJSNext.js 15React Native · ExpoPostgreSQLPrismaRedis · BullMQZodTailwindTypeScript

See it in action

Browse the storefront, or explore the consoles that power the stores and the brand behind the scenes.