Etsy Clone · Features

Etsy Clone Features: Built for the Seller Side

A thousand sellers listing five items each behaves nothing like fifty sellers listing a thousand. Onboarding cannot involve a phone call, commission cannot be one number, moderation is a daily shift rather than an occasional check, and support is a conversation rather than a form. Here is what ships, grouped by who touches it.

Request a Live Demo →See Pricing
Self-service seller onboarding
Per seller commission, not per platform
6 days to deploy
1,000 sellers
No interviews
How a Maker Gets Listing
01Registers with KYC and documents
02Operator approves from a queue
03Picks a plan with a listing cap
04Lists, then waits on moderation
05Bulk approve clears the queue
06Their own commission rate applies
131
Normalized MySQL Tables
4
Levels Commission Can Be Set At
9
Order Statuses, Per-Line State
6
Surfaces on One REST API
By Role

Feature Set by Role

Six surfaces on one REST API. On a maker marketplace the seller and the operator are the two roles that decide whether the thing works, so both are listed in full.

B

Buyer

  • Keyword search with autocomplete, filters and sorting
  • Category tree of unlimited depth and a shop directory
  • Product pages with galleries, video and photo reviews
  • Chat directly with a seller, with attachments
  • One basket spanning several independent shops
  • Wishlist and save-for-later that persist between sessions
  • Coupon, wallet credit and loyalty points applied together
  • Return opened with a reason and evidence, tracked to settlement
M

Maker

  • Registers themselves with KYC and document upload
  • Waits on an approval queue, not on a sales call
  • Picks a plan carrying a listing cap and a commission rate
  • Product CRUD with variants, stock and multi-image galleries
  • AI-assisted descriptions, SEO titles and image alt text
  • Chat with buyers about custom and made-to-order work
  • Order queue, refund responses and review replies
  • Wallet with commission visible and a withdrawal request flow
D

Delivery Agent

  • First-class identity with KYC, approval and zone assignment
  • Assignment feed with accept and reject
  • Navigation to the maker for pickup, then to the buyer
  • Live location broadcast while in transit
  • Status checkpoints from picked up through to delivered
  • One-time code verified at the door before handover
  • Earnings held separately from cash collected on COD
  • Payout request flow from the app
O

Operator

  • Seller approval queue with documents attached
  • Listing moderation with approve, reject and bulk actions
  • Full editing rights over anything on the platform
  • Commission set globally, per category, per seller or per product
  • Subscription plans with listing caps and reduced rates
  • Withdrawal queue across many small, frequent payouts
  • Every module behind its own permission
  • Eight report types over any date range, to Excel, CSV or PDF

The maker column is deliberately short on things a marketplace usually asks a seller to do. At a thousand sellers, every step you add to onboarding is a step most of them will not finish, and the ones who do not finish are the long tail your catalog depends on.

Compare

Etsy vs Miracuves Clone vs Building From Scratch

The same capability, three different paths. Every row that separates them is a seller-side row, because that is where a maker marketplace actually breaks.

CapabilityOriginal EtsyMiracuves CloneGeneric commerce script
Seller onboardingFully self-service at scaleSelf-registration with KYC and document upload, then an operator approval step - no interview requiredAn admin creates each vendor by hand
Commission granularityCategory-level, publishedGlobal, per category, per seller or per product - so you can sign one maker without repricing everyoneOne platform rate
Listing limits and plansPer-listing feesSubscription tiers carrying product-count caps, reduced commission and featured placementUsually absent
Moderation at volumeAutomated and staffedA queue with approve, reject and bulk actions, plus full editing rights over any listingOne row at a time, if at all
Buyer-to-seller conversationCentral to custom ordersDirect chat with attachments, alongside a threaded ticket queueA contact form to the platform
Many small payoutsYes, continuouslyA withdrawal queue with approve, deny and mark-processed, against per-seller payout detailsManual bank transfers and a spreadsheet
Basket across shopsYesOne basket spanning several independent sellers, shipping estimated per shop, delivery status per lineOne seller per order
Source codeNot availableComplete Laravel 12 backend and all three Flutter projects, unobfuscated, no licence callbackOften encrypted files or a licence check
Time to liveNot applicableSix working daysWeeks, then months on the seller-side gaps

The first two rows are the ones to test. Ask any provider to onboard a seller without an administrator touching the database, then give that one seller a different commission rate from everybody else.

End to End

How It Works, End to End

A maker joining, listing, selling and getting paid - traced through every queue it passes and every balance it moves.

01

The maker onboards without you

Registration with KYC and document upload, then a wait in an operator approval queue. At a thousand sellers you cannot interview anyone, so the pipeline has to hold quality without holding people up. The documents are attached to the approval decision rather than emailed to somebody.

02

They choose a plan, and the plan sets the ceiling

Subscription tiers carry product-count limits, a reduced commission rate, featured placement and priority support, billed on a cycle with a trial and a grace period on failure. A small maker starts cheap with a low cap and upgrades to list more, which is the natural revenue curve on this model rather than a paywall bolted onto it.

03

Listings arrive faster than anyone can read them

Seller-submitted products land in a moderation queue with approve, reject and bulk actions, and the operator keeps full editing rights over anything on the platform. With many small sellers this is a daily shift, so bulk is not a convenience - it is the difference between a queue that clears and a queue that grows.

04

The buyer asks a question before they buy

Buyer-to-seller chat with attachments, alongside a threaded support ticket queue. On a maker marketplace this carries real commercial weight: custom requests, sizing questions and made-to-order arrangements all happen here, because there is no options-and-quote builder in the base platform.

05

One basket, several independent shops

A basket can hold items from several makers at once, each with shipping estimated per shop. Coupon, wallet credit and loyalty points stack on the same order, tax comes from the zone rules, and placement is guarded by an idempotency check.

06

Each maker is charged their own rate

Commission is taken from the seller wallet on completion at whatever rate applies to that seller - global, category, per-seller or per-product - and reversed automatically on refund. That granularity is what lets you sign a maker worth signing without repricing everybody else on the marketplace.

07

Many small payouts, on many different cycles

Withdrawal requests queue for approve, deny or mark-processed against each seller's saved payout details. On this model the payout queue is high-frequency and low-value rather than the reverse, and every movement pairs with an append-only history row so any balance can be re-derived rather than trusted.

Nine statuses carry the order from pending payment to delivered, with a delivery status per line so one maker shipping early does not misrepresent the rest of a multi-shop basket.

Deliberate

Every Feature Earns Its Place

Feature lists are cheap. These are the ones that exist because a specific thing goes wrong on a marketplace of many small sellers without them.

CapabilityWhy it is not optional
Self-service registration with KYCBecause at a thousand sellers you cannot interview anyone, and a marketplace where an administrator creates each vendor by hand has a headcount ceiling on its own catalog growth.
Documents attached to the approvalBecause approving a seller from an inbox means the evidence lives in someone's email. Attached to the decision, it is auditable a year later when it matters.
Commission set per sellerBecause the maker you most want to sign is the one who will negotiate, and a single platform rate means every negotiation reprices your entire marketplace.
Listing caps on plansBecause on a maker model the natural upgrade trigger is wanting to list more, not wanting a better dashboard. Caps turn growth into revenue without adding a fee to anything that sells.
Bulk approve and rejectBecause listings arrive faster than anyone reads them. A moderation queue you can only work one row at a time is not slow, it is a queue that never empties.
Full operator editing rightsBecause a small seller's listing will be wrong in ways they cannot see, and asking them to fix it is slower and less reliable than fixing it.
Buyer-to-seller chat with attachmentsBecause custom and made-to-order work is negotiated, not configured, and without a channel for it those orders simply do not happen on your platform.
A basket across several shopsBecause a buyer browsing makers will want two things from two sellers, and a one-seller-per-order model turns that into two checkouts and usually one sale.
A withdrawal queue built for frequencyBecause small sellers withdraw often and in small amounts. A payout process designed for fifty monthly transfers breaks at a thousand weekly ones.
Append-only ledgers per actorBecause with many sellers on different rates and different cycles, a balance you can only read is a balance you cannot defend when one of them disputes it.

None of these are exotic. They are the ten places where a marketplace built for fifty large sellers stops working when it has a thousand small ones instead.

Stack

The Technology Behind the Features

Deliberately ordinary choices, because the developers who maintain this after handover should already know all of it.

BackendLaravel 12 on PHP 8.2, organised into nWidart modules so AI, Blog and Tax are separable rather than tangled through the core.
Data131 normalized MySQL tables with reversible migrations, soft deletes on customer, seller, agent and product rows, composite indexes on the hot paths, and append-only wallet histories.
APIOne REST API in versions v1, v2 and v3 serving the storefront, the seller panel, the operator console and all three Flutter clients. Six surfaces, one contract.
MobileThree Flutter Android projects - buyer, seller and delivery agent - transferred into your repository unobfuscated. The projects compile for iOS; store builds are quoted separately.
MessagingBuyer-to-seller chat with attachments and a threaded ticket queue, both in the core rather than bolted on, because on this model the conversation is part of the transaction.
PaymentsEleven gateways integrated, plus operator-defined offline methods and cash on delivery, with settlement records held per gateway and per currency.

Why per-seller commission is a schema property, not a setting

Commission resolving at four levels - global, category, seller, product - means the rate applied to any given line is looked up rather than assumed, and that lookup has to exist in the data model from the beginning. Platforms that store one platform rate can add a per-seller override later, but every historical order, every reversed commission and every payout already computed used the old assumption. On a marketplace whose entire commercial strategy is signing individual makers on individual terms, that is not a feature you retrofit.

Laravel 12PHP 8.2, nWidart modules
131Normalized MySQL tables
4 levelsCommission resolution
Redis 7Cache, queue, session

Everything above transfers into your repository. There are no encrypted files and no licence callback of any kind.

Honest Readiness

What Is Not Included in the Base Package

Everything above is in the base build and demonstrable in the live demo. These are not, and the hub names them rather than implying them away.

Scoped separately, or yours to own

  • An options and quote builderNamed on the hub as scoped work, and it is the fashion-of-this-category caveat: on a maker marketplace, personalisation, made-to-order and custom pricing are common. The base build handles them through buyer-to-seller chat rather than through a configurator, which works and is not the same thing. If structured options are core to your model, scope this at the start.
  • iOS applicationsThree Android builds ship. The Flutter projects compile for iOS, quoted as an add-on with signing and store submission.
  • Gateway credentialsEleven gateways are integrated; each needs your own merchant account and its own approval.
  • SMS and email providerIntegration-required - your accounts, your sender reputation, your deliverability. With many sellers this carries more notification volume than a conventional marketplace.
  • Firebase projectPush notifications across all three Android apps run through your own Firebase project.
  • OpenAI keyThe AI module generates descriptions, SEO copy and alt text against your key, with per-feature token quotas and a per-call cost log. On a maker marketplace this is often the difference between a listing that ranks and one that does not.
  • Catalog data and seller recruitmentProducts, imagery and the makers themselves are the business, and they are yours. The onboarding pipeline ships; the people walking through it do not.
  • Tax ratesTax classes bind per zone, but the rates for your jurisdictions are yours to set and yours to keep current.
  • Seller tax handlingThe platform computes tax on the order. Whether individual makers are separately registered, and what that obliges you to collect or report, is a question for your accountant rather than a switch in the console.
  • ISO 27001 and SOC 2Neither certificate is held and neither is claimed. The platform is ready for the evidence gathering; certification is a separate programme.

The options builder is the one to weigh honestly. Chat covers custom work well enough for most maker marketplaces, and badly for any model where the buyer is expected to configure and price a product themselves.

Development Company

See how Miracuves compares to agencies and freelancers

The deployment process, two modelled reference deployments, and how to test self-service onboarding and per-seller commission before you hire anyone - on the Development Company page.

See the comparison →
FAQ

Frequently Asked Questions

How is this different from the Amazon Clone?
Same platform, same price, different operating model on the page. The Amazon Clone is written for the general multi-vendor marketplace. This one is written for a marketplace of many small independent sellers, so it leads on self-service onboarding, commission set per seller, subscription tiers with listing limits, continuous moderation and buyer-to-seller chat. Choose by whether you expect fifty sellers or five thousand.
Can sellers onboard without us doing anything?
Almost. They register themselves with KYC and document upload, and then wait on an operator approval step with those documents attached to the decision. That is deliberate - at a thousand sellers you cannot interview anyone, so the pipeline has to hold quality without holding people up, but it should not let anyone list unreviewed either.
Can I give one seller a different commission rate?
Yes, and it is one of the main reasons to pick this over a general commerce script. Commission resolves at four levels - global, per category, per seller and per product - so you can sign a maker worth signing on their own terms without repricing everybody else on the marketplace.
Is there a product options or quote builder?
No, and the hub says so plainly. Custom requests, sizing questions and made-to-order arrangements are handled through buyer-to-seller chat with attachments rather than through a configurator. That works well for most maker marketplaces. If you need buyers to configure and price a product themselves, an options and quote builder is scoped and quoted separately, typically inside the two-to-eight week band.
How do subscription plans work?
Tiered packages carrying product-count limits, a reduced commission rate, featured placement and priority support, billed on a cycle with a trial and a grace period on failure. On this model the natural upgrade trigger is wanting to list more items, which turns catalog growth into revenue without adding a fee to anything that actually sells.
Can a buyer order from two sellers at once?
Yes. One basket spans several independent shops, with shipping estimated per shop and a delivery status per line, so one maker shipping early does not misrepresent the rest of the order. A one-seller-per-order model turns a two-shop basket into two checkouts, and in practice that means one sale.

Onboard a seller in front of us, then reprice them alone

That is the demo worth asking for. Everything else on a maker marketplace follows from those two things working.

Ready to launch a marketplace for independent makers?

Deploy in six days with self-service onboarding, commission set per seller, subscription tiers with listing caps, a moderation queue built for volume, and full Laravel 12 source on infrastructure you own.

Talk to Us →
Miracuves · Etsy Clone Solution Feature set and scoped add-ons cross-verified against the live hub, 2026-08-21