Key Takeaways
- A vendor count without a date attached cannot be planned against, because the date is what converts the count into an onboarding rate and the rate is what sizes the tooling.
- At ten makers almost nothing needs automating, since human judgement is cheap relative to the work and automating it removes information rather than adding capacity.
- A hundred makers is the line where manual stops working quietly: the inbox becomes a queue with states, judgement becomes written rules, and the payout run becomes a scheduled job with an exception list.
- Only three decisions genuinely have to assume the larger roster, namely the ledger, per-vendor commission as a first-class field, and vendor identity on every row, because those determine what gets recorded.
- Vendor count and catalogue size scale independently, so dividing expected products by expected vendors tells you whether you have a roster problem or a catalogue problem before anyone scopes a build.
Roster Planning Signals
- Write the vendor count and its date into the brief before anything else gets discussed.
- Do the first twenty approvals by hand, then automate exactly what you actually did.
- Build the ledger, per-vendor commission and vendor identity for a roster ten times your target.
- Divide expected catalogue by expected roster and read the median to find your real problem.
- Call five makers and ask about products, change rate, payout expectations and photography.
Real Insights
- Almost every first-year argument inside a marketplace team is really an argument about a roster number nobody wrote down, which is why so many of them cannot be settled.
- Building thousand-vendor machinery at ten vendors buys complexity you pay for daily and use never, since relevance cannot be tuned without queries and moderation rules cannot be tuned without violations.
- Keeping ten-vendor habits at a hundred is the quieter failure, because nothing breaks and the backlog simply grows until makers who applied weeks ago stop waiting.
- Support load and payout failures both scale with the roster rather than with revenue, so one percent of a thousand vendors is ten people waiting for money every single cycle.
- Miracuves ships a multi-vendor speciality food marketplace where onboarding, per-vendor commission, catalogue control and scheduled payouts already exist, so your roster target becomes a configuration question, and eligible ready-made scopes follow a 6-day deployment path for the build itself.
The call had been going well for forty minutes. The founder described the product fluently: makers apply, get approved, build a catalogue, take orders, get paid on a schedule. Commission per vendor. Delivery zones. Nothing vague, nothing hand-waved.
Then the engineer asked the only question left. How many makers, and by when. The pause was long enough to be uncomfortable, and it ended with the answer every scoping call receives at least once: as many as we can get.
That is not a number, and nothing can be planned against it. A marketplace built for ten makers and one built for a thousand share a feature list, a vocabulary and a demo. They are different products wearing the same name, and almost every decision worth arguing about sits downstream of that single count.
This article is about one variable: how many vendors a multi-vendor speciality food marketplace is meant to carry, what changes at ten, a hundred and a thousand, and which decisions must assume the larger number even when you launch with eleven.
Nobody asks how many makers a marketplace like Goldbelly is being built for, and that number sizes the entire build.
The Question Nobody Asks Before a Food Marketplace Build
Ten vendors and a thousand vendors are two different platforms, whatever a marketplace like Goldbelly looks like from outside.
Scoping conversations start with features because features are easy to talk about. They are also the least discriminating thing anyone could discuss at this stage. The feature list for a ten-vendor marketplace and a thousand-vendor one is nearly identical on paper: onboarding, approval, catalogue, commission, payouts, zones.
What differs is throughput, and throughput never appears on a feature list. It appears in how many applications arrive in a week, how many listings need a human eye, and how long the payout run takes. None of that is visible in a demo.
How Many Makers, and by When
A count without a date is a wish. A hundred vendors in year three describes a ten-vendor build with a plan. A hundred by month four describes a hundred-vendor build starting now, because months one and two go into the tooling that makes month three survivable.
The date converts a static number into a rate, and the rate sizes the machinery. Ten vendors a month is a person with a checklist. Ten a day is a queue with states, owners and a measurable backlog. The end count is the same. The build is not.
Two Products Wearing the Same Name
Both have a vendor spine: document checks, approval, per-vendor commission, catalogue control and scheduled payouts. How the business model works is the same in both, since the roster is the asset and supply is the constraint that decides everything else.
What changes is whether those words describe a habit or a machine. At ten, the spine is a founder, a shared inbox and a Tuesday morning. At a thousand, it is a set of jobs that run whether or not anyone logs in.
A Ten-Vendor Speciality Food Marketplace
At eleven vendors the founder knows the bakery closes on Mondays and which cheese producer answers within the hour. That knowledge is genuinely an asset, and it is why most of the software you are about to be sold is unnecessary at this size. Automating that judgement removes information rather than adding capacity.
Onboarding Is a Conversation
You meet the maker, read their registration and food handling paperwork yourself, and approve them because you have judged them rather than because they passed a rule.
You do not need a queue with six states, because you never have two applications in flight. What you do need even at ten is the record: who approved this vendor, on what date, against which documents, and when those expire. The queue can wait. The record cannot.
Discovery Is One Page
Eleven makers fit on one screen. A buyer scrolls, reads eleven names, picks. Ranking is meaningless because there is no long tail to surface. Teams build search here anyway, because search feels like a marketplace and a grid feels like a shop. The grid is correct.
The Payout Run Is a Tuesday Morning
Ten statements can be read by one person and ten transfers made by hand in under an hour. That is a defensible launch position, and plenty of marketplaces have run that way for a year without harm.
It is defensible on one condition. The ledger underneath has to be right from day one, because the transfer is the easy half. What is owed, against which orders, at which rate, minus which refunds, is the half no bank statement can reconstruct. Automate the transfer whenever you like. Never defer the accounting.
A Hundred-Vendor Food Marketplace: Where Manual Stops Working
The failure at a hundred vendors is not dramatic. Nothing crashes, no alert fires. Things take longer than the day allows, and the overflow lands on the vendors, who experience it as silence. An application sits nine days. A rejection goes unexplained.
The Queue Replaces the Inbox
Applications arrive faster than one person reads them, so onboarding stops being a task and becomes a pipeline: explicit states, submitted, documents outstanding, in review, approved, rejected, and a named owner on each.
The test is simple. If you cannot say how many applications are waiting and how long the oldest has waited, you are already past this line. The queue is the instrument that tells you whether the roster is growing or stalling.
Rules Replace Judgement
At ten vendors you read every listing. At a hundred with twenty products each, that is two thousand listings and nobody reads them twice. Judgement gets written down as rules: what a title may not contain, which claims need substantiation, which words route a listing to a human.
Writing rules is uncomfortable, because a rule is a judgement you must defend to the vendor it blocked. That is why it belongs on the plan rather than in someone’s head. Anything touching food claims, allergens or labelling belongs to your own counsel and local food authority; the platform records what was declared and when.
The Payout Run Becomes a Job
A hundred transfers by hand is not a Tuesday morning, it is a Tuesday, and a person doing them in sequence will eventually put the right amount in the wrong account.
So the run becomes a scheduled job that computes what is owed, moves money, records the result per vendor and reports exceptions. The important word is exceptions. What the features page calls a scheduled payout is two things: a calculation you trust and a list of the ones that failed.
A Thousand-Vendor Food Marketplace: Discovery Is the Product
At a thousand vendors you no longer have a roster. You have a market with its own concentration and quiet churn, and most of your vendors are people you have never spoken to. The operator’s job stops being recruitment and becomes population management.
Onboarding Is a Funnel With Drop-Off
People start an application and do not finish it, so onboarding acquires the vocabulary of a funnel: started, documents uploaded, approved, first listing published, first order received. Every step loses a share of those who entered it.
The largest loss is rarely the document step. It is the gap between approved and first listing, where a maker discovers that describing forty products with photographs is a weekend of work nobody mentioned. An approved vendor with an empty catalogue is one you paid to acquire and will never earn from.
Moderation Becomes Sampling
Nobody reviews a thousand catalogues. Moderation turns into sampling plus triggers: a random share of new listings, everything from a vendor in their first month, and re-review whenever a complaint or refund rate moves.
That is a genuine loss of control, accepted in exchange for operating at all. The compensating control is speed rather than completeness: you must be able to pull a listing or suspend a vendor within minutes.
A Maker Who Is Not Found Is a Maker Who Leaves
Marketplaces concentrate. A minority of vendors take the majority of orders without anyone designing it that way, and the churn among everyone else is the cost of bad discovery, not a fact of nature.
So categories, search relevance and ranking stop being features and become the product. Every ranking decision allocates revenue across your own roster, and it is where featured placement starts earning, because a vendor pays for visibility precisely when visibility is scarce.
What Actually Changes, Line by Line
Six dimensions change as the roster grows, and not at the same rate. Some scale with vendor count, some with catalogue size, and one changes shape rather than just getting bigger.
Image Source: AI-generated visual by Miracuves
Treat that arithmetic as an example, not a benchmark; real figures depend on your category. The point is that a manual habit produces a straight line, and a straight line meets the hours in a month sooner than anyone plans for.
Onboarding Throughput Is the First Constraint
Throughput is not applications received. It is applications carried from submitted to first listing published, per week, by the people you actually have. Suppose each takes forty minutes of attention across documents, a call, an approval and a nudge about the catalogue.
A hundred vendors is then roughly sixty-seven hours of work. Wanting them live in eight weeks means one person spending a full day a week on nothing else, before anyone asks a question. Onboarding binds first and is the dimension most often left out of the plan.
Reporting changes shape rather than size. At ten vendors you read rows. At a thousand you read distributions: median payout, the share of orders taken by the top decile, the count of vendors with zero orders in thirty days. That last one is the churn list, and it is always built two quarters late.
The same six jobs at three roster sizes
| Dimension | Ten vendors | A hundred vendors | A thousand vendors |
|---|---|---|---|
| Onboarding | A conversation and a record | A queue with states | A funnel measured for drop-off |
| Catalogue moderation | Read everything | Written rules plus exceptions | Sampling plus complaint triggers |
| Payout run | One person, one hour | A scheduled job plus exceptions | Batches, retries, a standing owner |
| Support | The founder’s phone | A shared queue with targets | Self-service first, humans after |
| Discovery | One page, no search | Real search and filters | Relevance and ranking as product |
| Reporting | Read the rows | Weekly totals and backlog | Distributions and churn |
Support and Payout Failures Both Scale With the Roster
These two lines are underestimated together and for the same reason. Founders model both against buyers and orders, when both are functions of how many vendors are on the roster.
Support Load Per Vendor
Every vendor is a small business with its own anxieties about money, and every one will contact you. Assume, illustratively, one and a half contacts per vendor per month. At ten that is nothing. At a hundred it is a part-time role. At a thousand it is a team with a rota.
Self-service first does not mean a help centre. It means the vendor answers their own question inside their own panel: where is my next payout and what is in it, why was this listing rejected, what rate applied to this order, which refunds hit my statement.
An article ending with the words contact support is not self-service, it is a queue with extra steps. Building those screens is cheaper than hiring against them, one of the quieter arguments for an owned white-label delivery platform over a rented one you cannot extend.
Payout Duration and the Failure Queue
At ten vendors the payout run takes minutes and its duration is irrelevant. At a thousand it has a start, an end and a middle in which it can be interrupted, which is an operational fact before a technical one. A cycle finishing at two in the morning with nobody watching is a support incident that begins at nine.
Failures are per vendor rather than per amount: a closed account, wrong details, a recipient who never completed verification. The rate stays roughly constant as the roster grows. One percent of ten vendors is a rounding error. One percent of a thousand is ten makers every cycle, each waiting for money, which is a standing role rather than a bug.
The Trap of Building for the Number You Want
Founders plan for the number they hope to have, because that number is the one in the pitch deck. It produces a specific, expensive failure: a platform carrying machinery for a population that does not exist, operated by three people who work around it daily.
Thousand-Vendor Machinery at Ten Vendors
Automated moderation with nothing to moderate. A ranking algorithm arbitrating between eleven vendors. Three subscription tiers with nobody on two of them. Each carries a daily cost in complexity and needs real behaviour to tune against, and you cannot tune relevance without queries or a rule without violations.
Building them early does not front-load the work, it front-loads the wrong version of it. The 36-Month TCO Comparison: SaaS Delivery Builders vs. Owned White-Label Engines makes the same point about rented platforms: complexity you carry is complexity you pay for.
Ten-Vendor Habits at a Hundred
This failure is quieter and worse. Nothing breaks. The backlog grows, and nobody notices that the oldest application is three weeks old because they have been looking at the newest ones.
The makers who applied three weeks ago concluded that nothing was happening and stopped waiting. You never see that churn, because it happens to people who never became vendors. A marketplace can lose its supply-side growth entirely while every internal chart still points upward.
A vendor target with no date on it
A hundred vendors is not a plan until you say by when. The count shapes the roster, the date sets the rate, and the rate decides whether onboarding is a checklist or a pipeline.
Automating work you have never done by hand
If nobody has personally approved a vendor or written a rejection reason, the automation encodes assumptions rather than practice. Do the first twenty by hand, then automate what you did.
One global commission rate
Convenient at ten, structural at a hundred. The moment you negotiate differently with one maker, a single rate becomes a schema change touching orders, statements and published history.
Treating vendor count as catalogue size
Twenty makers with three hundred products each is a catalogue problem in a roster problem’s clothes. Import tooling, variants and availability sync fix it. Onboarding queues do not.
Leaving the payout failure list unowned
Every cycle produces transfers that did not land. At a thousand vendors that is a recurring list of people waiting for money, and if no role owns it, it surfaces as complaints.
Planning the roster without talking to five makers
Product counts, update frequency, payout expectations and whether anyone can photograph the goods are learned in five phone calls, never from a spreadsheet.
Which Decisions Must Assume the Larger Number
A few decisions are effectively irreversible, not because the code is hard to change but because they determine what gets recorded. Anything that changes what you record cannot be applied retroactively, because the past does not contain the data.
Image Source: AI-generated visual by Miracuves
The Ledger and the Payout Model
Every movement of money should exist as an entry attached to a vendor: order value, commission taken, refund returned, adjustment applied, transfer made. Balances are derived rather than stored, and a statement is a query rather than a document someone assembled.
Add a ledger in year two and it starts from an opening balance you had to guess. Every dispute before that date is unanswerable. You can pay vendors by hand for a year without harm, but you cannot record informally for a year and formalize afterwards.
Per-Vendor Commission as a First-Class Field
The rate belongs to the vendor, not the platform. Build it that way on day one even if every vendor shares the same value, because the first negotiation and the first category exception arrive earlier than anyone expects.
The related property is that the rate is frozen onto the order at settlement, so changing it never rewrites what already happened. That is what makes a statement defensible, and it is worth reading the revenue lines this platform supports with that constraint in mind.
Vendor Identity in the Data Model
Every row that could belong to a vendor must carry the vendor from the beginning: orders, order lines, listings, images, payouts, refunds, messages, delivery preferences. Retrofitting a vendor column across a live schema is the worst week a marketplace ever has, and an avoidable one.
The second half gets missed. A vendor is an organization, not a login. The bakery will want the owner, a manager and a weekend assistant to have different access, and a model where vendor equals user account cannot express that without a migration through authentication and permissions.
Which Decisions Can Safely Wait
The mirror of that list is longer and more reassuring. Anything that mainly saves operator time can wait until the time saved is real. Deferring is not ignoring: each item should carry a trigger, a number at which it stops being optional.
Automated Moderation and Search Ranking
Both need data you do not have. A classifier trained on forty listings learns forty listings. A ranking model tuned against eleven vendors is a sort order with ambition.
Deferring automated moderation is only safe while the manual escape hatch exists, meaning you can suspend a vendor or pull a listing immediately and have that action recorded. Speed of removal is the control that lets you postpone prevention.
Self-Service Onboarding and Tiered Plans
Self-service onboarding removes the conversation, and at ten vendors that conversation is the most valuable research you will do. Every application handled personally teaches you what confuses makers and which document nobody has.
Tiered plans are pricing fiction until you know what vendors value enough to pay for. Sell one plan, or none, until a vendor asks for something it does not include. That request is the tier. None of this contradicts the vendor-side capabilities already in the build; it is about sequencing which you switch on.
Vendor Count Is Not the Same as Catalogue Size
Two marketplaces can both claim a catalogue of twenty thousand products. One has a thousand makers with twenty products each. The other has ten makers with two thousand each. They need different software, and both get quoted as the same project if the brief names only the product count.
A Roster Problem and a Catalogue Problem
A roster problem is about people: onboarding throughput, document expiry, payout failures, vendor support, commission variation, suspensions. It scales with relationships maintained.
A catalogue problem is about objects: bulk import, variants, stock and availability, lead times, images at volume, search indexing and the sync that keeps it honest. It scales with products and with how often they change, a point The Out-of-Stock Trap: Why Cheap Delivery Scripts Ruin Restaurant Relationships makes from the vendor’s side.
How to Tell Which One You Have
Divide the expected catalogue by the expected roster and read the median rather than the mean, because one very large vendor distorts the average and hides the shape of everyone else.
That last line deserves emphasis. Two thousand stable products is a one-time import and a quiet life. Two hundred products whose availability changes daily is a live synchronization problem that will take more engineering attention than the other eighteen hundred ever will.
What to Ask a Vendor Before You Can Plan at All
Four questions, asked of five real makers in your category, resolve more scoping ambiguity than a month of internal workshops. None can be answered from a spreadsheet, and all of them change the build.
How Many Products, and How Often They Change
Ask for the count, then ask what changed last month. A maker with twelve products who reformulates seasonally is an easy catalogue. A maker with four hundred across sizes, flavours and gift sets, half of which sell out on a Saturday, is not.
Ask how they track what they have right now. If the answer is a whiteboard in the kitchen, availability will be wrong on your platform by default, and the design problem becomes making wrongness cheap to correct.
How They Want to Be Paid
Payout cadence is a vendor expectation long before it is an engineering choice. A producer on thin working capital feels a fortnightly cycle very differently from a weekly one, and that shows up as reluctance to join rather than a complaint afterwards.
Ask what they are paid into and by which instrument, because the answer varies by market and sets both your failure rate and your reconciliation work. Ask what their current wholesale terms look like too. You compete with those terms whether or not anyone says so.
Whether They Can Photograph Anything
The honest answer is usually no, and this question quietly decides whether your marketplace looks like one. Catalogue quality is among the strongest predictors of whether a vendor ever sells, and most small producers have four phone photographs taken in bad light. At a hundred vendors, producing images is a budget line rather than a good intention.
The fourth question travels with it: can they deliver themselves, do they need your riders, or is collection acceptable. Coverage is drawn as delivery zones with riders you or your vendors run, and national carrier shipping is a different business with different logistics that this build deliberately does not attempt.
Writing the Brief So the Number Is In It
Most briefs describe a thing. The useful ones describe a load. That separates a quote you can hold someone to from one padded against an unknown you never named, and it takes a single paragraph. It is usually the paragraph that is missing.
Name the Count and the Date
Replace “a marketplace for speciality food makers” with something a team can size. “A marketplace that must onboard a hundred and twenty makers in six months, forty of them in month one, with a median of twenty-five products each, weekly payouts, and per-vendor commission between eight and eighteen percent.”
Every clause maps to a decision. The rate decides whether onboarding is a queue. The median decides whether you need bulk import. Weekly payouts decide the run cadence. Variable commission decides the data model. Four architectural consequences in one paragraph, and a food delivery app development engagement scoped against it looks nothing like one scoped against a noun.
A Firm Number Buys a Firm Quote
A team quoting against “a marketplace” must price the worst plausible reading of that word, because they will be held to whatever you meant. Padding is not dishonesty, it is the rational response to an unbounded requirement.
Give them the number and the ambiguity collapses. That is the conversation worth having with a team that has built this category before, and it changes what the delivery window means, since a ready-made scope moves fast precisely because the vendor spine already exists. Read what that window actually covers before planning a launch date around it.
Founder Decision Signals
Speed
Name the vendor count and its date before anything else. The rate it implies decides whether onboarding is a checklist or a pipeline with states, and that sets most of the schedule.
Cost
Do by hand first whatever you intend to automate later. Twenty approvals by hand cost a week and produce an automation that matches practice. Automation written first encodes assumptions.
Scalability
Build the ledger, per-vendor commission and vendor identity as though the roster were ten times larger. These three decide what gets recorded, and nothing recorded informally can be formalized in hindsight.
Market Fit
Divide catalogue by roster before scoping. A low median per vendor is a roster problem, solved with onboarding and payouts. A high median is a catalogue problem, solved with import and availability.
Related reading: ready-made or custom for a food gifting marketplace and marketplace gifting, slots and standing orders.
Final Thoughts: The Number Is the Brief
Decide the number first. It sizes a marketplace like Goldbelly far more than the feature list ever will.
Almost every argument a marketplace team has in its first year is really about a number nobody wrote down. Whether to build search. Whether to automate approvals. Whether one commission rate is enough. Each has an obvious answer once the roster size and its date are on the page, and none at all while they are not.
The discipline is to plan for the number you will actually have, build the three irreversible things for a roster ten times that size, and refuse everything else until a backlog forces it. That is the logic Migrating from SaaS to Owned Infrastructure: A Peak-Hour Performance Comparison applies to when an owned platform starts paying for itself.
If you have a number and a date, the rest is a scoping conversation rather than a research project. Bring both to a consultation and we will map your roster target against what already exists and what genuinely needs building. Browse our food delivery solution range or the wider solution catalogue first, read Sub-2 Second Tracking: Load-Testing GPS Delivery Updates on Flutter and Laravel if local delivery at volume is part of the plan, and use what a build of this shape involves when scale is the open question.
FAQs
What does a Goldbelly clone script cost for a food marketplace?
Plan for the number you will realistically have at the end of the period you are planning, with a date attached. A hundred vendors in year three is a ten-vendor build with a plan. A hundred by month four is a hundred-vendor build starting now. The date converts a count into an onboarding rate, and the rate is what actually decides how much tooling you need.
What does a ten-vendor food marketplace not need to build?
Search ranking, automated moderation, self-service onboarding and tiered plans. Eleven makers fit on one screen, so there is no long tail to surface. A classifier trained on forty listings learns forty listings. And self-service onboarding removes the conversation that is teaching you what confuses makers, which document nobody has, and what they assume about being paid.
What changes when a food marketplace reaches a hundred vendors?
The inbox becomes a queue with explicit states and a named owner, because applications arrive faster than one person reads them. Judgement becomes written rules, because nobody reads two thousand listings twice. And the payout run becomes a scheduled job that reports exceptions, because a person making a hundred transfers by hand will eventually put the right amount in the wrong account.
Which food marketplace decisions must assume more vendors?
Three. The ledger, where every movement of money is an entry attached to a vendor. Per-vendor commission as a first-class field, frozen onto the order at settlement. And vendor identity on every row that could ever belong to a vendor. These decide what gets recorded, and nothing recorded informally for a year can be formalized afterwards.
How do I tell a roster problem from a catalogue problem?
Divide the expected catalogue by the expected roster and read the median rather than the mean. Under roughly thirty products per vendor is a roster problem, fixed with onboarding, payouts and vendor support. Over roughly three hundred is a catalogue problem, fixed with bulk import, variants, availability and search. A high rate of change is a sync problem regardless of size.
What should I ask a maker before writing the brief?
How many products they have and what changed last month. How often those change and how they track availability today. How and how often they want to be paid, and into what. And whether they can photograph anything, because most small producers cannot, and somebody has to produce images. Also ask whether they deliver themselves or need your riders.
Why does support load surprise marketplace founders?
Because they model support against buyers and forget they have acquired a second population of users. Assuming one and a half vendor contacts per vendor per month, ten vendors is nothing, a hundred is a part-time role and a thousand is a team with a rota. Payout failures behave the same way: one percent of a thousand is ten people waiting for money every cycle.
What should the brief actually say about vendor count?
Name the number and the date in one sentence, along with the median products per vendor, the payout cadence and whether commission varies. Each clause maps to a decision: the rate decides whether onboarding is a queue, the median decides whether you need bulk import, and variable commission decides the data model. A quote against that is firm, where a quote against a marketplace is padded.
Miracuves is an independent software development company. We are not affiliated with, connected to, sponsored by, or endorsed by any company or product named in this article.
Terms such as “X Clone” are used descriptively. It is how the software industry refers to building a platform with functionality comparable to a known service, and how clients search for it.
The entire design and codebase of our products is built by our own team. Our products contain no code, design, graphics, or content originating from any third-party website or applications.
All third-party names and marks referenced in this article are the property of their respective owners, referenced solely to identify the services discussed.
