Every marketplace I've built had the same hidden problem — and it wasn't the code.
It was roles.
A multi-vendor marketplace looks simple from outside: sellers list, buyers buy. But the moment you add an admin, a seller, and a customer, every feature has three versions. Who sees what. Who can edit what. What happens to an order when a seller is suspended mid-delivery.
Three things I've learned shipping this kind of product:
1. Design the roles before the tables.
Role-based access isn't a feature you add later — it shapes every API and every dashboard. On the marketplace I built with Node.js and React, all three roles run from one API, with permission checks in the middleware, not scattered through the UI.
2. Integrations break at the edges, not the middle.
Connecting an HRMS to Odoo ERP taught me that two-way sync fails on edge cases — a record updated on both sides at once, or deleted on one side but still alive on the other. Handle the edges first.
3. Plan for money going out, not just in.
Stripe for collecting payments is easy. Stripe Connect for paying tutors on a tutoring marketplace — splits, payouts, timing — is where the real design work lives.
I'm Muhammad Ahmad, a full-stack developer in Lahore working with Laravel, Next.js, React, Node.js and MySQL. I build SaaS and business web apps from database to deployment.
The projects above are in my Work tab. If you're building a marketplace, dashboard, or any product with multiple user types, I'd love to hear what you're working on.Every marketplace I've built had the same hidden problem — and it wasn't the code.
Excited to share the latest web redesign projects for Codex⚡
The goal was to pair technical credibility with a more approachable, modern financial aesthetic while preserving the depth and complexity that make Codex a high-profile data provider.
The result is a visual direction designed to resonate across the spectrum, from crypto builders and neofinance founders to enterprise-scale exchanges like Coinbase. 💻
That's the whole of Penwave's design system. Every colour is read from the app's Tailwind config, and each ramp has one job: cream for the page, beige for badges, tea green for avatars, celadon for every border, muted teal for all the text.
Instrument Serif sets the headings and the post body. Inter runs the interface, 300 to 600.
In the clip the palette builds a story card, colour by colour.
Do you give every colour in your system a job, or keep a few spare? 👇
To your question: one job per colour, with a single spare accent kept for promos. Cream for the page and celadon for borders is easy to hand over to a team. Why zero bold weights?
A modern hotel management web application designed to simplify room bookings, guest management, and hotel operations through a clean, user-friendly interface.
Built with React.js, Node.js, Express.js, and MongoDB.