Goldbelly Clone Features: A Vendor Spine, and Local Fulfilment
A marketplace of independent makers lives or dies on two things: whether a vendor can run their own storefront without calling you, and whether they are paid correctly on a schedule. Both are built here. One thing is not, and it is stated before anything else: fulfilment is local delivery by riders you or your vendors run. Carrier shipping is not in this build.
Request a Live Demo →Full OverviewFeature Set by Role
Five surfaces over one Laravel backend, arranged around the vendor rather than around the restaurant.
The Maker
A small producer running their own shop: their catalogue with variations, add-ons and allergen notes, their own photographs, their own hours and holidays, items marked sold out in one tap, and a payout statement they can read themselves. 503 files across 29 modules, because a maker with two staff cannot phone you every time a batch runs out.
The Buyer
They browse vendors, categories and products with filters and a home feed you curate, open a maker's storefront, build a basket and check out. Thirteen gateways plus wallet credit, cash and offline methods, with split tender reconciled against the order rather than blended into one figure.
The Gift Sender
Buying for somebody else, with recipient details and the delivery slot carried on the order record itself rather than bolted alongside it in a notes field. That is what makes a gift a first-class order the platform can schedule, track and report on rather than a special case somebody handles manually.
The Vendor Manager
Applications, document checks, approval and go-live as a recorded workflow with the operator and timestamp attached. Commission set per maker, or a monthly plan instead, so the terms a vendor was signed on are a query rather than an email somebody has to find a year later.
The Merchandiser
The category structure buyers browse, the home feed, and featured positions sold to vendors competing for attention, scheduled and reported so placement revenue is measurable rather than anecdotal. On a marketplace of makers, what appears first is a commercial decision.
The Finance Desk
One scheduled disbursement job settling every approved vendor from what was actually charged, with statements, exports and overlap locks. Vendors forgive most things and never forgive being paid wrong, which is why this is the job the whole platform is arranged around.
Vendors cannot read each other: catalogue, order and payout data resolve against the vendor that owns them, so a maker signed into their own panel sees their own business and nothing else.
Clone vs Generic Script vs a Shop-per-Vendor Plugin
Most routes to a multi-vendor marketplace hold up until the first payout run.
| What decides it | Miracuves Goldbelly Clone | A multi-vendor storefront plugin |
|---|---|---|
| Signing a vendor | A recorded workflow with checks and approval | An account somebody created manually |
| Terms per maker | Commission or a plan, set per vendor | One global rate for everybody |
| Paying vendors | One scheduled run, with overlap locks | A spreadsheet and a bank transfer |
| What a vendor can check | Their own statement, whenever they like | Whatever you email them |
| Changing a vendor's rate | Old settlements unaffected, frozen at the time | Last quarter recalculates itself |
| Gifting | Recipient and slot on the order record | A note in a comments field |
| The vendor's own tools | 503 files across 29 modules, in source | A cut-down view of your admin |
| Source code | Yours outright, no per-order royalty | Plugin licences, renewed annually |
Goldbelly itself is the reference for what a speciality food marketplace looks like; it is not a product you can buy or self-host, and its nationwide shipping model is specifically what this build does not do. The comparison worth making is the second column against the third, and against a custom build, which is on the Development Cost page.
How It Works, End to End
Seven stages, running from a maker applying to a maker being paid.
A maker applies and is approved
Application, document checks, approval and go-live run as a recorded workflow with the operator and timestamp attached, so who approved a vendor and on what terms is a query rather than a memory. It is the first thing an acquirer or a dispute asks about.
Their terms are set individually
Commission per vendor, or a monthly plan instead of it, rather than one rate across the roster. On a marketplace of independents the ability to sign a sought-after maker on different terms from everybody else is frequently what gets them signed at all.
They build their own storefront
A surface carrying their own name and catalogue, with sizes, options, extras and allergen notes modelled as variations rather than separate products. You keep visibility over category structure, availability and pricing changes without having to make them.
A buyer browses and orders
By vendor, category or product, with filters and a home feed you curate, showing only the makers who can actually fulfil to that address. Thirteen gateways plus wallet credit, cash and offline methods, with split tender reconciled against the order.
Gifting and scheduling share one spine
Ordering for somebody else, choosing a slot for later, or setting a standing weekly order all run on the same order system, with recipient details and the chosen slot carried on the order record rather than as three separate mechanisms nobody can report across.
It is fulfilled locally
Riders you run, vendors delivering with their own staff, or collection in person. Coverage is drawn as delivery zones with their own charges and rules, and a buyer outside a maker's zone cannot order from them. This is the boundary of the build and it is stated plainly.
Every vendor settles from one run
A single scheduled disbursement pays every approved maker from what was actually charged, with statements, exports and overlap locks so a retry settles the same cycle to the same figures. Change a vendor's rate next month and their last statement still says what it said.
Offers, first-order discounts, free delivery thresholds and loyalty points run alongside, with each campaign funded by you or by an individual vendor and the split recorded either way.
Every Feature Earns Its Place
Each row is here because a multi-vendor marketplace stops working without it, not because a competitor lists it.
| Module | Why it is in the base build |
|---|---|
| The vendor as a first-class record | Terms, permissions, catalogue ownership and payout history hang off the vendor rather than being inferred from an order. Everything else about running a marketplace of independents follows from that record existing properly. |
| Per-vendor terms | One rate across a roster means the maker you most want cannot be signed on the terms it takes to get them. Setting commission or a plan per vendor is what turns a rate card into a negotiation you can actually win. |
| Idempotent payout runs | The disbursement job touches every vendor at once, and a repeat is far worse than a delay. Computing from snapshots with overlap locks means a retried run settles the same cycle to the same figures rather than paying your entire roster twice. |
| A statement a vendor can read | Makers forgive most things and never forgive being paid wrong. Letting them check their own numbers instead of asking you converts your most common support conversation into a page they open themselves. |
| Gifting on the order record | Recipient details and a chosen slot held on the order rather than in a note is what lets gifting be scheduled, tracked, reported and refunded like any other order. In a comments field it is a manual process pretending to be a feature. |
| Vendor isolation | Catalogue, order and payout data resolving against the owning vendor is not a nicety on a marketplace of competitors. A maker who can see another maker's numbers is a platform nobody will join twice. |
| Charges frozen at settlement | Commission is written onto the transaction and disbursement reads that snapshot, so neither a settings change nor a retried run alters what a vendor was owed. It is the property that makes a statement worth trusting. |
| Storage selectable at runtime | A marketplace of makers is mostly photographs, and they accumulate without shrinking. Local disk or S3-compatible storage with a primary and a fallback is what stops media growth becoming a migration. |
A built-in till captures counter and phone orders in the same system, so a maker with a physical shop reports through one platform rather than reconciling two.
The Technology Behind the Features
Conventional and easy to hire for, with the vendor and payout spine as the part that was designed rather than assembled.
One Laravel monolith owns every business rule and the five surfaces sit over one versioned API, so a vendor approved in the console is live in the storefront, both apps and their own panel within the same request.
What Is Not Included in the Base Package
The first two items decide whether this platform is right for you at all, so they are stated before anything else rather than in an appendix.
Fulfilment is local, not carrier
Coverage is drawn as delivery zones and orders are carried by riders you or your vendors run, or collected in person. Connecting a parcel carrier so makers can post orders nationwide, with rate lookup, labels and tracking, is not built. If nationwide shipping is your proposition, that is a scoped integration rather than a configuration.
No cold chain handling
Packaging rules, temperature constraints, ship-by windows and the day-of-week logic that perishable goods need are not in the build. For a speciality food marketplace this is a real limitation rather than a technicality, and it belongs in the first conversation if your catalogue is chilled or frozen.
The platform ships in test mode
One-time passcodes are exposed for testing, cross-origin rules are permissive and transport and frame headers are not emitted, all named in the documentation rather than found later. No second factor sits in front of console staff, on a console that can change what a vendor is paid.
Vendor accounting is an integration
Per-vendor statements and exports ship. Pushing them into an accounting system, or generating vendor-side invoices in a particular jurisdiction's format, is scoped separately, and it is asked for early on marketplaces where makers are registered businesses rather than sole traders.
Three things are scoped separately
Signing and releasing the iOS builds, bringing console access under your identity provider with a second factor, and pushing vendor, order and payout rows into an analytics stack your team already runs. Each is quoted before it starts rather than assumed into the price.
What is built is real
Vendor onboarding as a recorded workflow, per-vendor terms with a guard, catalogue ownership resolved per vendor, a 503 file vendor application in source, gifting and scheduling on the order record, idempotent payouts with statements, the built-in till, and a control map published against OWASP categories.
What no codebase supplies is the roster. A curated list of makers who cannot easily be signed elsewhere is worth more than any feature here, and assembling it is your work rather than software's.
See how Miracuves compares to agencies and freelancers
The deployment process, the nine questions worth asking anyone bidding on a multi-vendor build, the red flags, and the Flyereats engagement we delivered in 2025 - on the Development Company page.
Frequently Asked Questions
Can makers ship orders nationwide?
How are vendors onboarded and approved?
Can different vendors be on different terms?
How does gifting work?
What stops a payout run paying twice?
Does it work for things other than food?
Onboard a vendor, then pay them
On the demo, approve a maker, set their terms, take an order against their catalogue, then run the disbursement and read the statement they see.
Explore the Goldbelly Clone
The roster is the asset. The payout run is the retention.
A curated list of makers who cannot easily be signed elsewhere is worth more than any feature, and a maker paid correctly on schedule does not shop around. Both run on a platform you own outright.
Talk to Us →Miracuves is an independent software development company. We are not affiliated with, connected to, sponsored by, or endorsed by Goldbelly.
“Goldbelly Clone” is used descriptively. It is how the software industry refers to building a platform with functionality similar to Goldbelly, and how clients search for it.
The entire design and codebase is built by our own team. The product contains no code, design, graphics, or content originating from the Goldbelly website or applications.
Goldbelly and all other third-party names and marks are the property of their respective owners, referenced here solely to describe the category of software offered.
