Skip to content
All build stories

Next.js · PostgreSQL · Prisma

How I built a multi-vendor marketplace with Next.js and PostgreSQL

By Rohan Mondal · · 2 min read

Toyco India Marketplace screenshot

A toy brand wanted its own marketplace, where many sellers could list products, without handing its search traffic to the big platforms. That meant building three products at once: a storefront for shoppers, a workspace for sellers and an operations panel for admins, all sharing one catalogue. Here is how I structured it.

Three users, one catalogue

The hardest part of a marketplace isn't the shop front. It's that shoppers, sellers and admins need very different tools while touching the same products and orders. I modelled that explicitly with three roles (customer, seller and admin) and kept every permission check on the server.

Authentication is cookie-based email and password, using signed JWTs (jose), so pages can be rendered on the server for search engines while still knowing who is signed in.

The data model comes first

Before writing UI, I designed the PostgreSQL schema in Prisma. It covers everything a real marketplace needs:

  • Users and roles, vendors and their KYC documents
  • Categories, brands and products
  • Addresses, persistent carts and coupons
  • Orders, order items and reviews

Every API input is validated with Zod, so a malformed request is rejected at the edge of the system instead of corrupting data deeper in.

Seller onboarding with KYC

Sellers register, complete a profile and upload KYC documents before their products go live. Seller APIs cover the profile, KYC records, product submission and editing, and visibility into their own orders only.

Uploads go through an authenticated upload API. In development, files are stored locally; in production, the same API writes to S3-compatible object storage, so storage can scale without code changes.

Admin operations that save hours

The admin panel manages categories, products, vendors and coupons. For catalogue work there's a bulk product import, because nobody wants to add hundreds of toys one form at a time.

SEO built in, not bolted on

The whole point was to own search traffic, so SEO was part of the architecture from day one:

  • Server-rendered home, brand, category and product pages
  • Product and breadcrumb structured data on every product page
  • A generated sitemap, robots rules and per-page metadata
  • A PWA manifest, and shopping signals such as delivery and cash-on-delivery messages and a pincode check

Checkout and accounts

Customers get saved addresses, a cart that persists between visits, coupon-aware checkout and an order history. Because checkout creates real orders in the database, the seller and admin panels see them immediately.

Related services: E-commerce Development · Web App & SaaS Development

Want something like this built?

Share a few details and within 24 hours I'll send ideas, a timeline and a free, fixed quote.