DevoraX is a software agency. We built Pastel Marketplace, a live antiques marketplace at mypastel.com with verified sellers, curated collections, funds held between payment and fulfilment, and insured global shipping. That is one antiques build, not a portfolio in the category. It suits dealers, consignment businesses and collector platforms trading one-of-one pieces. Fixed price, quoted after a free 30-minute call.
What do you actually ship in an antiques marketplace build?
Base scope is a working two-sided marketplace. A buyer-facing storefront with curated collections and individual listing pages. Seller onboarding with verification held on the account. Listing creation built around heavy photography and a provenance narrative. A transaction flow that holds funds between payment and fulfilment. Shipping with rates, labels, tracking and insured cover. An admin console for curation and order oversight.
On Pastel Marketplace that split across four systems rather than one. Next.js renders the storefront. Firebase holds accounts, listing data and media. Sharetribe carries the transaction. Shippo carries the shipment. The two parts that hold legal and financial risk, money movement and cross-border logistics, sit inside platforms built for them instead of being reimplemented in application code.
The full in-scope and out-of-scope lists are on this page. The short version is that the marketplace works end to end, and anything requiring a commercial contract of yours is scoped and quoted separately.
Who is this built for?
Businesses trading one-of-one goods where the value sits in the object's history rather than a spec sheet. Antiques dealers, collectibles resale platforms, estate and consignment businesses, and anyone running a curated catalogue where each item sells once and is then gone.
The defining constraint is the data model, not the category. A conventional catalogue assumes a product record with variants, stock depth and a price repeated across identical units. An antique inverts all three. Each listing is a single record whose worth is carried by provenance, condition and the evidence behind them, and once it sells it has to retire cleanly rather than decrement a count.
If your catalogue has restock, SKUs and repeat units, the general page is the better starting point: /solutions/multi-vendor-marketplace-development. Come back here when the objects are unique and trust is the thing you are actually selling.
Which builds prove you have done this before?
Pastel Marketplace is the direct proof, and it is one build rather than a category portfolio. It is a luxury antiques marketplace on Next.js and Firebase, running publicly at mypastel.com, and the product is also listed on the App Store as Pastel Antique Marketplace. The client reports 12k+ curated items, 2.8k+ verified sellers, 48k+ collectors and a 98% positive review rate. Those are the client's figures, not measurements we took. The case study is at /projects/23.
Afriva E-Commerce Platform is the second. It is a four-role marketplace on Next.js 15 and Supabase, with admin, manager, seller and buyer dashboards and delivery tracking streamed from Postgres. The client reports $1.2M transacted, 1,245 active vendors and coverage across 120+ cities. It runs at afriva-buyer.vercel.app and the case study is at /projects/32.
Both front ends are open to inspection before you speak to us. What a visitor cannot see from outside is the seller and admin side of either platform, and the case studies describe that rather than demonstrate it.
How do you model provenance and one-of-one listings?
Provenance is narrative and evidence, not attributes, so it does not fit a variant table. On Pastel the weight of a listing sits on photography and the supporting history: where the piece came from, who owned it, what condition it is in now, and what backs those claims. The images have to substitute for handling the object.
That has two engineering consequences. Image handling becomes the dominant cost on every page, which is part of why the storefront is rendered with Next.js and uses its image pipeline. And listing state becomes delicate. A sold piece is gone permanently, so the catalogue has to retire it cleanly instead of decrementing inventory, and every surface showing it has to agree that it is gone.
It is also why that state belongs on the backend. Pastel's accounts and listing data sit in Firebase and its transactions in Sharetribe, so every client reads the same state rather than a second implementation of the same rules.
How do you keep one seller's data out of another seller's hands?
Verified status belongs on the account rather than drawn in the interface. It has to be stored, checked when a listing is created, and surfaced anywhere that seller appears. A buyer who sees the mark on a profile but not on the listing learns to distrust both, which is the whole reason it lives in one place.
Separation itself belongs in the data layer. Afriva's backend is managed Postgres through Supabase, so vendors owning products and products appearing in orders live in the schema rather than being reassembled in application code. That is where an ownership rule goes: expressed once and checked by the database, rather than implied by which button a screen renders. Supabase also bundles authentication with the database, so the identity that signs a user in is the identity the query runs as. We publish no security assessment of Afriva and do not offer its schema as a guarantee, but hiding a button is not a permission model.
The tenancy question in more depth: /solutions/multi-vendor-marketplace-development.
How is money held between payment and the piece arriving?
A marketplace payment is not a checkout. Funds move from buyer to platform, are held while the piece is packed and shipped, and reach the seller once the exchange completes. Commissions, refunds, disputes and payouts to sellers in different countries all hang off that single flow. On Pastel we used Sharetribe, which models it as a state machine, so the path between enquiry, payment, fulfilment and completion is enforced by infrastructure built for two-sided commerce. The frontend reads a transaction's current state and never takes custody of funds.
Shipping is the other half, and it is where antiques marketplaces usually break. Every sale is a one-off shipment. A framed print, a chandelier and a chest of drawers share no packaging profile, no dimensional weight and no obvious carrier, and sellers are not logistics professionals. Shippo sits in front of many carriers behind one interface: rate selection, label purchase, tracking and insured cover. For an irreplaceable object there is no replacement unit, so cover has to attach to the shipment itself.
What does the build look like, and what do you need from me?
It starts with a free 30-minute discovery call. After it you get a written fixed-price proposal with the scope enumerated. Nothing is built before you have agreed that document, and we do not bill hourly.
What we need from you is the commercial decisions, because they drive the data model and we cannot invent them. Your category and period taxonomy. Your verification policy, meaning what a seller supplies before they get the mark and who reviews it. Your commission and refund rules. Which countries you ship to and what you will not ship at all. Your photography standard for listings. And accounts in your own name with the payment and shipping providers, because the money and the carrier relationships should be yours from the first day rather than ours.
We deliberately publish no delivery timeline. Scope determines it, and quoting a duration before the scope exists is how these projects go wrong.
How is it priced, and what happens after launch?
Fixed price. You get a written proposal after the discovery call and the number does not move unless the scope does. Published starting points are MVP Starter from $2,900, Growth from $7,500, and Enterprise custom-scoped. They are indicative starting points, not quotes. A marketplace with held funds, seller verification and insured international shipping does not sit at the entry tier, and we will say so on the call rather than after you have signed something.
You own all code and IP on final payment. It lives in a repository you control and deploys to accounts in your name. There is no licence, no hosting lock, and nothing you have to keep paying us for in order to keep trading.
Support after launch is quoted separately. A marketplace with live sellers and money moving through it needs a different arrangement from one still in soft launch, so we price the one you actually have.
When should you not hire DevoraX for this?
If you need timed auctions with live bidding, reserve prices and proxy bids, do not hire us. No project we have delivered includes an auction engine, and bidding concurrency is its own discipline. Buy an auction platform, or hire a team that has shipped one.
If a native mobile app is the core of the product, start elsewhere. The stack we publish for Pastel is Next.js and Firebase, so native mobile is work we would scope from scratch. And if you want people you can redirect week to week on an hourly retainer, we are the wrong shape: the scope has to settle before the work starts.
If your budget sits below our published MVP starting point, a hosted marketplace product will serve you better than a custom build. Sharetribe, which we used on Pastel, sells its own platform, and starting there and replacing it later is a legitimate plan. DevoraX is also two people, Sameem Amjad and Usman. If you need ten engineers next month, that is not us.
Start with a scoping call
A free 30-minute call to work out what you are building and what is actually hard about it. If there is a fit you get a written fixed-price proposal. If there is not, we will say so on the call.
Book a call