Farfetch Clone Features: One Basket, Many Boutiques
The hard part of a luxury multi-brand marketplace was never the storefront. It is one basket becoming four supplier orders with four fulfilment states, onboarding hundreds of boutiques without a KYB backlog, and paying every seller the right amount on schedule with an approval trail behind each release. Those are the parts already built here. This is what ships, grouped by who touches it.
Request a Live Demo →See PricingFeature Set by Role
Four surfaces run from one platform and one API gateway. Each one is built for the person in front of it rather than being the same console with fields hidden.
The Shopper
Browses a 58-node luxury taxonomy through a mega-menu, lands on a product page carrying competing offers from different boutiques with their own price, condition and stock, and fills one basket across several sellers. Wishlists persist across sessions and devices, and a guest can look up an order and track a shipment without ever creating an account.
The Boutique
Onboards through KYB with document capture rather than an email thread, then runs its own hub: team access with role-based permissions, bulk feed import over CSV and API with job monitoring, category and attribute mapping for its own catalog, growth campaigns, statements and payout requests. It is a seller portal rather than a spreadsheet and an inbox.
The Catalog Reviewer
Works a review queue that stands between a seller upload and a live listing. Authenticity status, condition and provenance are first-class fields rather than free-text notes, which is the difference between a luxury marketplace and a general one. Offers are ingested with per-seller pricing and stock before anything reaches a shopper.
The Finance Operator
Sets commission rules by category and by seller tier, watches the settlement ledger accumulate against child orders, and releases payouts through maker-checker so no single person can both create and approve a release. Statements are what a boutique sees; the ledger behind them is what an audit tests.
The Risk and Support Operator
Fraud scoring runs before payment authorization, AML and sanctions screening sit in the seller lifecycle, and disputes have their own workflow rather than living in a shared mailbox. Thirty-seven admin routes cover catalog QA, commissions, seller lifecycle, risk, disputes, finance, regions and feature flags.
The Mobile Shopper
A 42-route Expo application covering browse, product, bag, orders and profile, plus seller tabs for boutique operations on mobile. It shares the same API gateway as the web storefront, so a price rule or a commission change applies to both without a second implementation.
Every capability here is built and demonstrable in the live demo. Where something needs a third-party account or a deployment decision before it works in production, that is stated against the feature rather than implied away.
Farfetch vs Miracuves Clone vs Building From Scratch
What each route gives you on the parts that decide whether a multi-brand marketplace can actually settle with its sellers.
| What decides it | Miracuves Farfetch Clone | Building from scratch |
|---|---|---|
| Time to a working marketplace | Six working days | A multi-year programme with a senior team |
| Product model | Master products with competing seller offers | Usually one product per seller, rebuilt later at cost |
| Multi-seller orders | Parent order splits into child orders with independent state machines | The engineering most marketplace templates never attempt |
| Commission | Rules by category and by seller tier | A flat percentage, until the first category argument |
| Payout control | Maker-checker approval before any release | A finance person with database access |
| Boutique onboarding | KYB with documents, team RBAC and bulk feed import | Email, spreadsheets and a growing backlog |
| Authenticity | Status, condition and provenance as first-class fields | Free-text notes nobody can filter or audit |
| Source code | Full monorepo, 29 services, yours to redeploy | Yours, at the cost of building all of it |
Farfetch itself is the reference for what this category looks like at scale; it is not a product you can buy or self-host. The comparison that matters commercially is the second column against the third.
How It Works, End to End
One basket, traced across four boutiques and two currencies, with every state change and every ledger entry written down.
The catalog is one product with many offers
A handbag is one canonical product record. Four boutiques attach competing offers to it, each with its own price, condition and stock. That structure is what luxury resale and multi-brand retail actually need, and it is the thing a single-seller storefront theme cannot be retrofitted into later.
Nothing goes live without passing QA
A review queue stands between a seller upload and a visible listing. Authenticity status, condition and provenance are structured fields, so a reviewer approves against a checklist rather than a paragraph. Bulk feeds arrive over CSV and API with job monitoring, and category and attribute mapping translates a boutique's own taxonomy into yours.
The basket spans sellers, and persists
One cart holds line items from several boutiques at once, for guests and signed-in shoppers alike, and carries through to a single checkout. Wishlists persist across sessions and devices. A guest who never registers can still look up the order and track the shipment afterwards.
Checkout resolves duties before it takes money
A checkout intent combines promotions, address validation, duty and tax by region, shipping options and a fraud scoring hook, and all of it resolves before payment is authorized. On cross-border luxury the duty line is the difference between a completed order and a refused parcel at the border.
One parent order becomes several child orders
The order service splits the basket into a child order per seller, each with an independent fulfilment state machine. Four boutiques can be at four different stages of the same purchase, and the shopper sees one order while each boutique sees only its own. This is the engineering most marketplace templates never attempt.
Commission is computed, not assumed
Rules apply by category and by seller tier rather than as one flat percentage across the platform. A premium tier boutique in one category and a new seller in another settle differently on the same order, and the ledger records how each figure was reached rather than only what it came to.
Payout releases only with a second approver
Settlement accumulates against child orders, statements are generated for each boutique, and a payout request moves through maker-checker so the person who prepares a release is never the person who approves it. Financial control here is structural rather than procedural, which is what an audit actually tests.
Every Feature Earns Its Place
Each module below exists because a luxury multi-brand marketplace stops working without it, not because a competitor lists it.
| Module | Why it is in the base build |
|---|---|
| Master products with offers | Four boutiques selling the same bag must be one product page with four offers, or your catalog becomes four near-duplicate listings and your search becomes useless. |
| Catalog QA queue | In luxury, one counterfeit listing that reached a shopper costs more than the queue costs to staff. |
| Authenticity and provenance fields | Structured fields can be filtered, audited and disputed against. A free-text note cannot. |
| Duty and tax at checkout | Cross-border luxury without a duty line produces refused parcels and chargebacks, which is a worse outcome than a lost sale. |
| Parent and child orders | Without the split, a delayed item from one boutique holds the whole order hostage and every seller sees every other seller's business. |
| Commission by category and tier | A flat rate cannot survive the first negotiation with a high-volume boutique, and repricing it by hand does not scale. |
| Maker-checker payouts | Separation of duty on money movement is the control an auditor looks for first, and the hardest to retrofit. |
| Bulk feeds with job monitoring | Boutiques will not hand-enter a thousand SKUs, and a silent feed failure is discovered when stock sells that does not exist. |
| Fraud scoring and AML screening | High-value goods attract card fraud, and sanctions screening in the seller lifecycle is not optional in most jurisdictions. |
Retail media on both sides, loyalty tiers, concierge and a catalog-grounded AI search service ship alongside these.
The Technology Behind the Features
What the platform is actually built on, and what that means for the team who inherits it.
Why the settlement layer is the number that matters
A luxury storefront can be built in weeks. What takes years is everything that has to agree behind it: a product model where several boutiques compete on one record, an order that splits into independent fulfilment states, commission that varies by category and tier, and a payout that no single person can both prepare and release. Around seventy tables is not a boast, it is a consequence of modelling those things properly instead of flattening them.
The stack is Node.js, Next.js and TypeScript on standard PostgreSQL, which matters when you hire against it and when a technical buyer runs due diligence on what you own.
What Is Not Included in the Base Package
Named here rather than discovered after the invoice.
Documented gaps and pre-launch work
Authentication hardening. JWT authentication at the gateway with rate limiting and role-based access across customer, boutique, seller and operator is built. There is no MFA, no refresh tokens, no token revocation, no silent renew and no admin step-up. These are documented gaps and pre-launch work, and they are named here because discovering them during a security review is worse.
File handling. No signed download URLs and no upload virus scanning. On a platform where boutiques upload documents and imagery, both belong on the pre-launch list.
Every external provider is your account. Stripe, PayPal or Adyen, SendGrid, Twilio, Firebase, Algolia and OpenRouter all run on credentials you hold. That is deliberate: they are accounts you should own rather than accounts we hold on your behalf.
Search beyond full-text. PostgreSQL full-text ships and works. Algolia is an upgrade with the sync adapter already written, and it becomes worth doing when the catalog and query volume justify it rather than on day one.
Enterprise single sign-on is available, not default. Auth0 integration provides enterprise SSO with JWKS validation using your own tenant and credentials, which is a deployment decision rather than something switched on by default.
The controls that are built are real: fraud scoring before payment authorization, AML and sanctions screening in the seller lifecycle, and maker-checker on every payout release.
See how Miracuves compares to agencies and freelancers
The deployment process, a deployed client case study, and what to check on settlement, catalog QA and authentication before you hire anyone - on the Development Company page.
Frequently Asked Questions
Can several boutiques sell the same product?
What happens when a basket spans four sellers?
How is commission calculated?
Is authenticity handled or just claimed?
Is search production-ready out of the box?
Are there any security gaps I should know about?
See one basket split across four boutiques, live
Ask for the demo and we will place a multi-seller order, watch it split into child orders, then release the payout through maker-checker in front of you.
Explore the Farfetch Clone
Ready to run a luxury marketplace that settles properly?
Deploy in six working days with the storefront, seller hub, admin command centre and mobile app included, your commission rules and regions configured with you, and the full monorepo on infrastructure you own.
Talk to Us →