Building Stylica: The Engineering Behind a Pakistani Fashion Marketplace
Ali Hamza on why Stylica exists, the stack behind it (React, Deno, MongoDB) and the rules that had to be enforced on the server — not in the app.
By Ali Hamza ·
Stylica started as a question I kept asking in Multan: why do the best boutiques in the city still run their entire business from a phone's chat history? They have the craft, loyal customers and good prices. What they lack is infrastructure — a store that never sleeps, a fair way to take orders and a clear record of who owes whom.
Stylica is my answer to that question, built as a Final Year Design Project in BS Computer Science at the University of Southern Punjab, and designed to run as a real business.
The problem, in one sentence
Pakistani shoppers want variety and trust; Pakistani boutiques want reach without building a tech company. A multi-vendor marketplace gives both, but only if its rules are strict enough that nobody has to take anyone else's word for anything.
The stack
- Web and apps: React with TypeScript, styled with Tailwind CSS. The same code ships as a fast website, an installable PWA that works offline, and Android/iOS apps through Capacitor.
- API: Deno 2 with the Oak framework. Deno runs TypeScript natively and only gets the permissions it needs (network, environment, read) — it cannot write files or run programs on the server.
- Database: MongoDB Atlas. Atlas runs as a replica set, which is what makes multi-document transactions possible.
- Validation: Zod schemas shared between the app and the API, so a rule like "commission is 0–100%" is written once and enforced in both places.
- Images: photos are uploaded straight to Cloudinary and served as AVIF or WebP at exactly the size each screen needs.
Rules that live on the server
The most important design decision was where the business rules live. A rule enforced only in the app is a suggestion; anyone can call the API directly. So these are checked on the server:
- Checkout is one transaction. Stock is decremented only if enough is left. If any item fails, nothing is charged and nothing is reserved.
- Orders follow a state machine. Pending → Confirmed → Shipped → Delivered → Settled. Skipping a step returns an error.
- Money is integer paisa. Commission is calculated as a rounded fee in paisa, and the vendor's credit is exactly the remainder. No floating-point surprises.
- Settlement is idempotent. A unique index guarantees one credit per order per boutique, so a repeated delivery event cannot pay twice.
- The ledger is append-only. Wallet transactions and admin audit logs can be added but never edited or deleted.
- Vendors see only their own data. The vendor id comes from the signed login token, never from the request.
Testing it like a business
The project is tested against the cases a real marketplace faces: two customers racing for the last unit (one succeeds, one gets a clear "sold out"), a replayed settlement (credited once), a customer trying to open an admin page (refused), a commission of 120% (rejected), plus load testing and Lighthouse checks for speed and accessibility.
Built for Pakistan
Everything is bilingual — English and Urdu with full right-to-left layout — and payment is Cash on Delivery because that is how most Pakistanis prefer to shop. The interface works from a small 320-pixel phone up to a desktop, in light or dark mode.
What is next
The goal is simple: make it as easy for a Multan boutique to sell nationwide as it is to post on Instagram, with better protection for everyone. If you run a boutique, open your store. If you want to understand the model in plain words, start with what a multi-vendor marketplace is. And if you just want a new suit, the shop is open.
— Ali Hamza, Founder & Lead Engineer, Stylica