DevoraX is a two-person software studio, founded in 2022, that builds multi-vendor marketplaces: a buyer storefront or app, a vendor portal, an admin console, payments, search and order tracking over one backend. The marketplace work behind this page is its founder Sameem Amjad's, most of it done as an employee of other companies: Afriva as an engineer at Webrange Solutions, Pastel's iOS app as a software engineer at Pastel, and the shared NestJS backend of Dooz Inspected Cars, which hired him directly. DevoraX now takes the same work directly: custom builds for operators a template will not fit, and custom features plus the native iOS and Android app for marketplaces already running on Sharetribe, which ships no native app.
What does a multi-vendor marketplace build include, and what is quoted separately?
A marketplace is four products sharing one database. A buyer surface for browse, search and checkout. A vendor portal for listings, stock and an order queue. An admin console for oversight of the catalogue and the order queue. A backend that owns the rules all three read.
Base scope covers those four, plus one payment provider integration, order records with status visible to buyer and vendor, server-rendered catalogue pages so the listings are indexable, and deployment to a live environment you can open and inspect.
What sits outside base scope is listed too, because agencies leave it ambiguous. Native iOS and Android clients on top of a web build are separate work. So are multi-carrier shipping, live location tracking, and third-party quote integrations such as financing or insurance. Each is a real integration with its own failure modes. Pretending one is a line item inside a fixed price is how fixed prices stop being fixed.
Who is this for, and which marketplace model is closest to mine?
This is for someone who has decided that independent sellers, rather than a single inventory, is the model, and that a template will not carry it. If a Shopify multi-vendor app covers what you need, use it. A custom build starts to pay when the vendor relationship is itself the product: verification states, inspection data, per-vendor terms, or a catalogue where every item is a single unit that retires on sale.
Three of the four products named below have their own page, because the models differ more than the word marketplace suggests. Collectibles and one-of-one resale is covered at /solutions/antiques-marketplace-app-development. High-ticket assets with published condition reports is at /solutions/used-car-marketplace-app-development. Mobile vendor discovery, where the vendor moves and the customer is trying to find it, is at /solutions/food-truck-ordering-app-development. Afriva, a general-goods marketplace, is the closest reference for a conventional catalogue with sellers, stock levels and delivery.
Which marketplaces has DevoraX's founder worked on?
Three: Afriva, built at Webrange Solutions; Pastel, the company's own antiques marketplace; and Dooz Inspected Cars, Dooz's own used-car marketplace in Jordan, which hired Sameem directly.
Afriva is a four-role marketplace on Next.js 15 and Supabase: admin, manager, seller and buyer dashboards with real-time order tracking. Sameem worked on it as an engineer at Webrange Solutions, on the Next.js 15 front end, the seller dashboard for inventory, pricing and order status, and the Supabase data layer. Its public link is a demo build of the buyer storefront, at afriva-buyer.vercel.app.
Pastel is a US-based marketplace for antiques, vintage decor and collectible art, built on Sharetribe and live at mypastel.com and on the App Store. Sameem has been a software engineer at Pastel since April 2026, working on its iOS app, which first launched in November 2025, before he joined. Dooz Inspected Cars runs an Angular web client and iOS and Android apps over one backend, and Dooz hired Sameem directly to work on that shared NestJS backend. Dooz's Google Play listing shows 100K+ downloads.
Food Magnet, also named on this page, is not a marketplace. It is a food truck discovery platform: a Flutter app and a React admin console on AWS Lambda, with live location tracking and Stripe. Sameem worked on it as an engineer at Zencloud, on a product that already existed. It is adjacent work, not a fourth marketplace.
How do you keep one vendor from reading another vendor's data?
A vendor boundary is a database property, not an interface one. A client-side check hides a button; it does not stop a request, because the request can be issued without the interface. Ownership is expressed in the schema, and the check runs where every client has to pass.
On Afriva that meant managed Postgres rather than a document store. Vendors own products, products appear in orders, orders split into shipments, and foreign keys and constraints give one authoritative place to state that a seller cannot mutate another seller's stock. Supabase also bundles authentication with the database, so the identity that signed a user in is the identity Postgres sees on the query, which removes the drift between what the interface believes and what the database permits.
Dooz's backend reaches the same place differently: valuation, inspection status and listing availability resolve server-side, so NestJS owns the rules and the three clients render state.
What happens when one basket spans several vendors?
This is where the complexity concentrates. It is the difference between a marketplace and a shop. One buyer checkout becomes several vendor orders with separate dispatch timelines, so the data model has to represent a parent purchase and its child shipments, then reassemble them into one legible screen.
Stock is the concurrency problem underneath it. With vendors listing independently, the same item can enter several baskets at once, so inventory decrements have to be atomic in the database rather than read-modify-write in application code. On a catalogue of single units, as with Pastel and Dooz, it is sharper still: a sold item has to disappear from search, saved lists and every client immediately, because stale availability destroys the trust the platform exists to create.
Status is the third piece. On Afriva, Supabase Realtime streams Postgres changes over a websocket, so a buyer's tracking view updates from the same row operations just edited. No polling interval, no reconciliation step.
How does the build run, and what do you need from me?
It starts with a free 30-minute discovery call. The output is a written fixed-price proposal setting out scope, what is included, what is excluded, and the price. Nothing is built before that document is agreed.
What we need from you is decisions, not documents. Who the roles are and what each is allowed to do. What states a vendor account can be in, and what each state permits. What a completed order means, and who is owed money at that point. Whether the catalogue holds stock-keeping items with quantities or single units that retire when sold. Those four answers determine the schema, and the schema is the expensive thing to change later.
We also need access to whatever the integrations require: a payment provider, hosting, and any third-party service the scope names. Who holds each of those accounts is settled in the proposal, per project, rather than promised as a policy here. The one ownership commitment we do make is in the section below.
How is it priced?
Fixed price, agreed in writing before work starts. No hourly billing and no retainer required to reach launch. The published starting points are $2,900 for MVP Starter and $7,500 for Growth, with Enterprise custom-scoped. Those are indicative starting points, not quotes. A four-role marketplace with split fulfilment and a payment integration is not an MVP Starter build, and we would rather say so here than on the call.
Fixed price is only honest if scope is honest, which is why the exclusions are stated on this page rather than discovered in month two. Add a requirement mid-build and it is quoted as a change, and you decide whether to take it. The alternative, absorbing it silently, is how an agency ends up shipping the cheapest possible version of something it promised.
Two people do the work: Sameem Amjad and Usman. You are not handed to an account manager after signing.
What happens after launch, and who owns the code?
You own all code and IP on final payment. That is the ownership commitment, stated at its edges. Owning the code is not owning every account the platform runs on: where hosting, payment and third-party accounts sit is a per-project decision recorded in the proposal, not a guarantee this page makes.
Support after launch is quoted separately rather than assumed. A support arrangement priced into a build fee is either padding, if you do not need it, or inadequate, if you do. Decide it once you can see the traffic.
Vendor onboarding is the part marketplace buyers ask about most. Afriva has admin and manager surfaces for catalogue and order oversight, and Pastel lets sellers open shops and list their own pieces. How a new vendor is reviewed and approved is your policy to set, and recruiting and vetting sellers stays yours.
When should you not hire DevoraX for this?
If a Shopify multi-vendor app, Sharetribe's hosted product or a marketplace template covers your model, buy it. It is cheaper than anything here and it will be running next week. Pastel itself is built on Sharetribe rather than on custom payment code, and the case for that generalises: marketplace money movement is a state machine with commissions, held funds, refunds, disputes and cross-border payouts, and reimplementing it is a poor trade without a reason.
Do not hire us if you need a committed launch date before anyone has seen the scope. We do not publish delivery timelines and will not invent one on a call.
Do not hire us if you need a certified compliance posture. DevoraX holds no certifications and has run no compliance audits, and a marketplace carrying regulated financial products should hire a firm that can evidence one. And if you have not yet decided what a vendor is allowed to do, that decision comes before a supplier does.
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