Use Sharetribe when your marketplace is a standard listing-and-commission transaction and you have not yet proved supply. For a large share of marketplaces that is the permanent answer, not a stage. Build custom when the domain data model, the role surfaces or native apps are the product. The line can also run through one project: our Pastel Marketplace is a custom Next.js storefront on Sharetribe's transaction layer. We never built the alternative, so read that as description, not verdict.
Key findings
- The build-versus-buy line ran through the middle of one of our own projects, not around it: Pastel Marketplace is a custom Next.js and Firebase build whose transaction layer is Sharetribe, which its case study calls the single most consequential decision on the project.
- In all three marketplaces the custom part was the domain data model and the role surfaces, not the payment flow: Afriva runs four role-separated dashboards with authorisation pushed into the data layer, Pastel treats seller verification as account state, and Dooz models inspections as versioned, indexed data.
- Two of the three ship an app store presence (Pastel on iOS, Dooz on Google Play and the App Store), which a hosted web marketplace product does not produce by default.
- For a marketplace with a standard transaction, an ordinary catalogue and unproven supply, a hosted product is the permanent answer rather than a stage before a custom build. Nothing in our record shows anyone outgrowing one, because our record contains no such case either way.
- Our indicative custom starting points are $2,900 (MVP Starter) and $7,500 (Growth), and nothing in the shape of Dooz fits the smaller band, so for some specifications the honest answer is to cut scope or stay hosted.
- Every scale figure here is client-reported and unaudited: 12k+ items, 48k+ collectors and 2.8k+ verified sellers for Pastel; 1,245 vendors and $1.2M revenue for Afriva; 20,000+ vehicles, 1.2B+ JD in transactions and 150+ inspection points per vehicle for Dooz.
What is actually being compared here?
Three options are on the table, not two. The first is a hosted marketplace product such as Sharetribe, where the vendor operates the infrastructure and supplies the marketplace transaction as a configurable process: enquiry, payment, fulfilment, completion, commission, payout. You configure it; you do not deploy it.
The second is an existing commerce platform with a multi-vendor app layered on top, most commonly Shopify. We have never built one, so it gets a section of its own below rather than a column in the table, and we describe it only where its vendors do.
The third is a custom application, where the data model, the role surfaces and the hosting are yours. The binary in the question is false in one important way: Sharetribe sells both a no-code hosted product and a developer platform that exposes the same transaction engine over an API. A custom frontend on a bought transaction layer is a real position, and it is the one most comparisons omit.
| Dimension | Hosted marketplace product (Sharetribe-type) | Custom build |
|---|---|---|
| Who operates the infrastructure | The vendor | You, or an agency you pay |
| Transaction process | Supplied as a configurable process; Pastel's frontend consumes it as a modelled state machine | Whatever you model, at the cost of modelling it |
| Data model | Users, listings and transactions as the platform defines them, extended with custom fields | Yours to define: Dooz models versioned inspection records, which the client reports at 150+ points per vehicle |
| Setup work | Configuration | Engineering, plus environments, CI and hosting |
| Native iOS and Android apps | Not the default path; a native client is a custom build against the API | Pastel ships iOS; Dooz ships Google Play and the App Store |
Why does an agency that builds custom marketplaces run Sharetribe inside one?
Pastel Marketplace is a custom build in our record, a Next.js storefront on Firebase live at mypastel.com and on the Apple App Store, and its transaction layer is Sharetribe. The case study calls using it rather than writing a payment flow from scratch the single most consequential decision on the project.
The reasoning is worth repeating. A marketplace payment is not a checkout. Money moves from a buyer to the platform, is held while a one-of-one antique is packed and shipped, and is released to the seller only once the exchange completes, with commissions, refunds, disputes and cross-border payouts attached. That surface area is larger than the storefront itself.
Sharetribe supplies it as a modelled state machine built for two-sided commerce, so the frontend reads a transaction's current state rather than taking custody of funds. What that decision does not tell you is whether the whole project should have been hosted. We never built that version, so the record establishes the choice was consequential, not that it was correct.
When is Sharetribe clearly the right answer?
There are four situations in which we would tell you not to hire us, and they are common. First, you have not proved supply. A marketplace with no sellers has nothing to transact, and no framework choice changes that; we hold no failure data, so treat that as mechanics rather than a finding. Until sellers list and buyers pay, every engineering hour funds a hypothesis.
Second, your transaction is standard: list, buy or book, pay, fulfil, release, commission. Third, your differentiation is not software, because curation, community and category expertise are not code. Fourth, your budget is below the build, and our own floor is $2,900.
One thing worth being plain about, because vendor pages are not: for many marketplaces the hosted product is the permanent answer rather than a stage before us. A configured marketplace taking real money is a finished business, not a prototype. That you will inevitably outgrow it is a sales line, and we have no evidence for it.
When is Shopify with a multi-vendor app the better choice?
We have never built this arrangement, so nothing here comes from our record. We describe it only as its vendors do: Shopify is a commerce platform for running a store, and multi-vendor capability is added by third-party apps installed on top.
It is right when you are the merchant of record and your vendors are really suppliers. If the catalogue behaves like products with variants and stock levels, if one party owns the customer relationship, and if you want an existing payments, tax and shipping ecosystem without integrating it, take that route. Configuration is less work than construction, and our custom floor is $2,900 before any change budget. For that reader this is the destination, not a stepping stone.
The requirements that pushed Afriva onto its own schema were four role-separated dashboards, each querying only the slice its role is entitled to with authorisation in the data layer, and one checkout splitting into child shipments on independent timelines. Whether a given app expresses those is a question for its documentation.
What did Pastel, Afriva and Dooz need that an off-the-shelf product does not give you?
Three projects in our record are the marketplaces this article rests on, each needing custom code for a different reason. We have not audited the record for every project that might be called marketplace-shaped, so read three as the evidence behind this piece, not a census of our marketplace work.
Pastel needed a catalogue where every listing is a one-of-one object carrying provenance rather than attributes, where seller verification is account state checked when a listing is created, and where curated collections cut across categories. Its transaction layer is still bought. Afriva needed four role-separated dashboards over managed Postgres, atomic stock decrements when one item enters several baskets at once, a parent purchase that splits into child shipments, and delivery status streamed from the database, not polled.
Dooz needed structured inspection records, which the client reports at 150+ points per vehicle, versioned so older reports still render and indexed so condition becomes a search facet, feeding an AI valuation. The common thread is the data model, not the payment flow.
| Marketplace | Transaction layer | What forced the custom build | Live surfaces | Client-reported scale |
|---|---|---|---|---|
| Pastel Marketplace (Next.js, Firebase) | Sharetribe | One-of-one provenance listings, curated collections cutting across categories, seller verification as account state | mypastel.com, Apple App Store | The client reports 12k+ curated items, 48k+ collectors, 2.8k+ verified sellers, 98% positive reviews |
| Afriva (Next.js 15, Supabase) | Not named in the record; order and inventory state sit in the platform's own Postgres schema | Four role-separated dashboards, parent orders splitting into per-vendor shipments, realtime delivery tracking | afriva-buyer.vercel.app | The client reports 1,245 active vendors, $1.2M total revenue, 120+ cities covered |
| Dooz Inspected Cars (Angular, React Native, NestJS, PostgreSQL) | Not named in the record; NestJS owns the business rules and PostgreSQL the transactional guarantees | Structured, versioned inspection records, AI valuation, financing and insurance quotes inside the buying flow | dooz.com, Google Play, Apple App Store | The client reports 20,000+ verified vehicles, 1.2B+ JD in total transactions, 150+ inspection points per vehicle, 98% satisfaction |
How do the cost shapes actually differ?
The headline price is the least interesting number in this decision, and it is also the one we are least able to give you. A hosted product is operating expenditure: a subscription plus payment processing, with no capital outlay. A custom build is capital expenditure plus a change budget, and it is the change budget that kills projects rather than the build price.
Our own model is a fixed-price proposal rather than hourly billing, with indicative starting points of $2,900 for an MVP Starter and $7,500 for Growth, and Enterprise quoted per project. Those are starting points, not quotes. Nothing in the shape of Dooz, three clients over one backend, versioned inspections, an AI valuation service, financing and insurance integrations, fits the smaller band.
We will not tell you what the alternatives cost. Two things are worth pricing yourself: the configuration, design and data-migration labour a hosted setup still takes, and what a custom build does at ten times the volume, where re-architecture is an engineering ticket like any other.
| Cost line | What we can state from our own record | Where the real number has to come from |
|---|---|---|
| Build or setup | Fixed-price proposals starting at $2,900 (MVP Starter) and $7,500 (Growth), Enterprise quoted per project. Indicative starting points, not quotes. | Any setup cost on a hosted product, including configuration, design and data-migration labour, has to come from whoever does that work. |
| Subscription | None. We charge no recurring fee and do not resell hosting; you pay your own infrastructure providers directly. | The vendor's current pricing page. Hosted marketplace products and commerce platforms are sold as tiered subscriptions; multi-vendor apps are priced by their own publishers, on models that vary. |
| Payment processing | Nothing. We integrate processors; we do not set their rates and we hold no invoices. | Your payment processor's current rates, plus any platform fee a marketplace product takes on top of them. Both have to be read from current terms. |
| Cost of a change | On a custom build, every change is an engineering ticket that someone has to scope, price and schedule. | On a configured product, a change is available only within what the product supports. Whether yours is supported is a question for the vendor's documentation. |
| What you hold at the end | Our contracts transfer code and IP to the client on final payment. | What a vendor account leaves you with if you stop paying is set by that vendor's terms. We have not tested any of them. |
Which parts should you never build yourself, even inside a custom build?
Even when the answer is custom, the answer is not custom everywhere. Pastel is the worked example: Next.js owns the storefront, Firebase owns accounts, data and media, Sharetribe owns the transaction, Shippo owns fulfilment. The two components carrying legal and financial risk, money movement and insured cross-border shipping, were bought. The two that define the product were kept.
The rule we apply is simple. If a component is regulated, adversarial, or maintained against somebody else's changing API, buy it. Multi-carrier shipping is the clearest case: a framed print, a chandelier and a chest of drawers share no packaging profile, dimensional weight or obvious carrier, and sellers are not logistics professionals.
Dooz applies the same rule at a different boundary. What it built is what makes it a product: inspection modelled as versioned data, valuation resolved server-side, and PostgreSQL guarantees that let a reservation, a listing state change and a financial record commit or fail as one unit. Financing and insurance quotes come from third parties on someone else's latency budget.
What does our record prove about this choice, and what does it not?
Less than the confidence of these headings suggests, so here are the bounds. DevoraX has been building since 2019, has 25 delivered projects all with published case studies, and holds 20 five-star Fiverr reviews from 16 clients across four countries. Three of those projects are the marketplaces here. A record of delivered work is by construction a record of what went well enough to publish, so nothing cancelled or abandoned would appear in it, and we do not claim there is nothing to appear.
We have never built the same marketplace twice, once hosted and once custom. There is no paired test, no migration in either direction and no instrumentation of either approach. The scale figures are what clients told us, not what we measured.
We are also an interested party. We sell custom builds, and the four situations listed earlier are precisely the ones where we lose the sale. They are here because for a large share of readers the honest answer is the product we did not build.
How should you decide, in order?
Answer four questions in sequence, stopping at the first clear no. Has supply proved itself? If sellers are not already listing, buy a hosted marketplace and spend the difference on recruiting them. For many marketplaces that is where this decision ends permanently, and there is nothing second-best about ending it there.
Does your transaction fit a standard process: list, buy or book, pay, fulfil, release, commission? If it does and your catalogue is ordinary too, a configured product is the finished answer and you should stop here rather than build around it. Pastel keeps a bought transaction layer inside a custom build, but that shape only becomes relevant once the next question is also a yes.
Does your domain need a data model the platform does not have: structured inspections, provenance, role-separated tenancy, multi-shipment orders? Do you need surfaces it does not produce, as two of our three do with native apps? Reach the fourth question with yes answers and a funded change budget, and a custom build is defensible.
Limitations
- Three marketplaces with case studies inside a 25-project record from one small agency. A record of delivered work is selection-biased by construction: no cancelled, abandoned or failed marketplace could appear in it, and we have not audited the record for every project that might be called marketplace-shaped.
- We have never built the same marketplace twice, once on a hosted product and once custom. There is no paired test, no A/B and no migration in either direction, so every comparison here is engineering reasoning rather than measurement.
- We have not run Sharetribe or a Shopify multi-vendor app as an entire client platform. Our direct experience of Sharetribe is its transaction layer inside Pastel, which is why the Shopify column was dropped from the structural table rather than filled with an object model we have never worked in.
- All outcome figures are client-reported and were not audited or instrumented by us. None carries a measurement date, a baseline or a comparison condition.
- DevoraX sells custom builds, so we have a commercial interest in this answer. The only prices in this article are our own indicative starting points, which are not quotes; no third-party pricing is stated anywhere, including in the cost table.
What this data cannot answer
- What Sharetribe, Shopify or any multi-vendor app will cost you at your transaction volume. We hold no invoices and quote no third-party prices, so those figures have to come from the vendors' current terms.
- Whether Pastel would have performed as well fully hosted, or Afriva on an off-the-shelf product. No counterfactual was built, so the comparison is untested.
- Whether any of the client-reported figures were caused by the build-versus-buy decision. There is no control group and no baseline anywhere in this record.
- How hard it is to migrate from a hosted marketplace to custom code, or back. No project in our record has made that move, so we have no migration experience to report.