Multi-vendor optical marketplace

AsaanOptics Marketplace

A multi-vendor marketplace for optical shops in Pakistan, with prescription ordering, nearby search and escrow-style checkout, currently in development.

Role: Sole developer: design and build
Platforms: Web, Backend & API
Status: In development, not launched
Timeline: 2026

Web application
E-commerce
SaaS product

Design prototype

Overview

AsaanOptics Marketplace is a multi-vendor e-commerce platform built only for optical stores. Independent shops apply to join, pass an admin review, and then list frames, lenses and accessories with size and color variants. Customers browse products from shops near them, attach their eyeglass prescription to an order, and pay into an escrow-style hold that is released to the shop, minus the platform commission, once delivery is confirmed.

It is three web apps on one API: a customer storefront, a vendor portal for running the shop, and a separate admin portal for governing vendors, orders and money. I designed it prototype-first, starting with a UI/UX specification and a 39-screen clickable HTML prototype, then built the working apps as a TypeScript monorepo.

The platform is in development and has not launched. The core marketplace loop is being built now, and the payment step is simulated: no real payment gateway is connected yet. The screens on this page come from the clickable prototype, which the Next.js apps reuse as their design system.

Built for: Independent optical shops that want an online storefront without building their own, customers buying eyewear and prescription lenses from nearby verified shops, and the operator who runs the marketplace.

The problem

The project brief starts from the state of optical retail in Pakistan: it is fragmented, and buying eyewear online carries little trust. Customers worry about counterfeit frames or lenses made to the wrong power, and cash on delivery leads to high return rates.

General marketplaces are not built for eyewear. They have no place for prescription values (SPH, CYL, AXIS, ADD and PD for each eye) or for frame measurements in millimeters, and most independent optical shops do not have the budget or skills to build their own online store and inventory tools.

The solution

I built a marketplace with three roles on one API. Vendors sign up, complete a shop setup wizard with documents and a map location, and wait for an admin to approve, reject or request changes. Once approved, they manage products and variants, orders, prescriptions, reviews, their wallet and analytics.

Customers find products sorted by distance from their location, filter them, keep a cart and wishlist (also as a guest), attach a saved or uploaded prescription, and check out. Behind the checkout, an order state machine controls who can move an order to each stage, and a ledger records every hold, release, commission and refund so that vendor wallet balances stay consistent with the order history.

Main features

What is built so far, taken from the code.

Vendor onboarding and approval
Shops move through draft, pending, approved, rejected, revision and suspended states. Vendors upload documents and pin their location in a setup wizard, and can edit and resubmit after a rejection or a revision request from the admin queue.
Escrow-style order flow
Payments are held after checkout and released to the vendor once the customer confirms delivery, with the platform commission recorded separately. The payment step is simulated for now, while the ledger and wallet logic behind it is implemented.
Prescription ordering
Customers save prescriptions with SPH, CYL, AXIS, ADD and PD for each eye, optionally with a photo of the paper prescription, and attach them to cart and order lines. Vendors get a dedicated screen to review incoming prescriptions.
Nearby shopping
Products can be filtered by radius and ranked nearest first based on the distance from the customer to each shop. Customers set their location from preset areas or with browser geolocation.
Optical product data
Products carry frame shape, face shape, material, gender and prescription support. Each variant has its own SKU, price, stock, color, images and frame measurements: lens width, bridge width, lens height and temple length.
Guest cart and order tracking
Guests keep their cart and wishlist in the browser, and signed-in customers use a server-side cart. Guest orders can be followed through a private tracking link.
Vendor portal
A dashboard with charts, plus screens for products, orders, prescriptions, reviews with replies, the escrow wallet and withdrawals, analytics, and settings such as delivery zones and notification preferences.
Admin governance portal
A separate app for the operator, covering the shop approval queue, vendors, orders, escrow, commission, content pages, support and settings. A manager for the product attributes used in vendor forms and storefront filters is still in progress.

Inside the product

Screens from the clickable design prototype, not a released product.

AsaanOptics Marketplace prototype hub introducing the customer, vendor and admin portals of the escrow-secured optical marketplace — The prototype hub links the three portals: customer, vendor and admin.

AsaanOptics Marketplace nearby marketplace prototype with a distance radius filter, a map of nearby shops with price pins and products sorted nearest first — Nearby shopping: a radius filter and products ranked by distance to each shop.

AsaanOptics Marketplace product page prototype for an aviator frame with frame specifications, an escrow notice and a 'Select prescription lens' button — Product page with frame specifications and the option to add prescription lenses.

AsaanOptics Marketplace five-step prescription lens ordering prototype with frame, lens type, power, upload Rx and summary steps — Guided prescription lens ordering in five steps.

AsaanOptics Marketplace checkout prototype with delivery address and delivery method choices and an order summary showing the amount held in escrow — Checkout summary showing delivery, GST and the amount held until delivery is confirmed.

AsaanOptics Marketplace vendor dashboard prototype with revenue, orders, escrow balance and rating cards, a revenue chart and an escrow status donut — Vendor dashboard prototype, shown with sample data.

AsaanOptics Marketplace vendor escrow wallet prototype with available, held and pending balances, an escrow transactions table and a payout method — Vendor wallet separating held, pending and withdrawable earnings.

AsaanOptics Marketplace admin vendor approval queue prototype with pending, approved, revision and rejected counts and a table of shops awaiting review — Admin approval queue for new optical shops, with fictional sample shops.

AsaanOptics Marketplace admin escrow console prototype with held, pending, released, refunded and disputed totals and the payment to release flow — Admin escrow console, shown with sample figures.

Development and architecture

The project is an npm workspaces monorepo. One Express and TypeScript REST API serves three Next.js 15 App Router apps: the customer storefront, the vendor portal and the admin portal, which is meant to run on its own domain. A shared package holds the Zod schemas, enums and types used by both the API and the frontends, and a UI package holds the design system carried over from the prototype.

Data lives in MySQL through Prisma, with 22 models covering users, shops, products and variants, carts, orders and order events, escrow transactions, wallets, withdrawals, reviews, delivery zones and prescriptions. Money is stored in decimal columns. Images go to Cloudinary, and only their IDs and URLs are kept in the database.

This is the second version. I first built it with Vite, React and a Sequelize backend in JavaScript, then rewrote it as a typed Next.js and Prisma monorepo so the API contracts and the three apps could share one source of truth.

Ledger written in transactions: Every hold, release, commission and refund entry is written in the same database transaction as the wallet balance change, so the ledger and the balances cannot drift apart.
Role-gated order state machine: Orders follow a 13-state lifecycle. On top of role-based access, I added a map of which actor (customer, vendor or system) may perform each transition, so a valid user still cannot push an order into a stage that is not theirs.
One pricing function: Delivery fee, same-city waiver, GST and commission are all calculated in a single function, with rates set in configuration. Commission is taken from the product subtotal only, so delivery and tax never change what the vendor earns.
Stable distance-sorted pagination: For nearby search, the API first finds matching products and their shop coordinates, calculates the distance to each, filters by radius and ranks them, then loads full details only for the current page. Results keep a stable order from page to page.
Token handling: Sign-in uses a short-lived access token and an httpOnly refresh cookie. Refresh tokens are rotated and stored only as SHA-256 hashes, passwords are hashed with bcrypt, and admin accounts are created by seeding, never through public sign-up.
Prototype-first design system: The 39-screen HTML prototype and its conventions document came first. Its styles were then moved into a shared UI package, and the vendor and admin portals were kept as separate apps so their styles never clash with the storefront.