Three proposals, three different products, and no way to compare them
In short
The numbers differ because the proposals are for different products. Each responder silently answered 5 scope questions: how deep the seller tooling goes, whether money is split and reconciled or exported and settled by hand, whether moderation is software or a policy sentence, how many mobile surfaces exist, and how much of the admin console is included. Line the proposals up on those 5 first.
Key takeaways
- Variance is information: it tells you which parts of the brief were unanswerable, not which responder is expensive.
- The seller surface and the money model account for most of the spread, and neither is usually written down.
- A brief that says nothing about moderation gets priced as a policy sentence by one responder and as tooling by another.
- Mobile is not one axis but four: buyer web, buyer app, seller app, and whether the apps are native or wrapped.
- Picking the middle number buys the middle interpretation, which nobody wrote down and nobody is committed to.
- The fix is one re-brief and one re-quote against a fixed scope, not a negotiation with three responders in parallel.
The three numbers are not three answers to one question. They are three answers to three questions, because a marketplace brief that does not fix the seller surface, the money model, the moderation posture, the mobile footprint and the admin console leaves 5 decisions for whoever is reading it — and every responder answers them in the direction their team is strongest. Line the proposals up on those 5 axes before comparing anything, and most of the spread explains itself as scope rather than margin.
This is worth doing carefully rather than quickly, because the variance is the most useful signal you will get for free. It is a map of exactly which parts of your brief were unanswerable, produced by 3 independent readers at their own expense.
Extract what each proposal assumed, before comparing anything
- Build one sheet with the 5 axes as rows and the 3 proposals as columns. Fill it only from what each document actually says.
- Where a proposal is silent on an axis, write "silent" rather than guessing. Silence is the finding — it means that responder priced their own default and you have not yet seen it.
- Count the deliverable surfaces each proposal commits to. A surface is anything with its own screens and its own release: buyer web, buyer app, seller web, seller app, admin console. Different surface counts alone explain a large share of any spread.
- Separate integrations from features. List every third-party system each proposal names — payments, identity, messaging, mapping, accounting — and mark whether it is inside the number or noted as an assumption.
- Mark design in or out, and to what depth. A proposal including research, flows, a design system and per-surface visual design is describing a different engagement from one that assumes your design is supplied.
- Only now compare. If the sheet has 3 different sets of answers, you have not received 3 quotes for one product, and no amount of negotiation makes them comparable.
The five axes, and the two readings each one has
Each axis has a light reading and a heavy reading, and both are legitimate interpretations of a brief that did not say. The right-hand column is the question that forces the choice into the open.
| Axis | The light reading | The heavy reading | The question that settles it |
|---|---|---|---|
| Seller surface | Sellers submit a form and email the operations team for anything else | A seller product: onboarding and verification, listing management in bulk, calendar or inventory, order queue, earnings and statements, notifications | What does a seller do on a Tuesday morning, and where do they do it? |
| Money model | One charge to the buyer, payouts exported and settled by hand each cycle | Split payment on Stripe Connect, Adyen for Platforms or Razorpay Route, with commission, conditional release, refunds, adjustments and a ledger that reconciles | Who holds the funds between purchase and payout, and what happens to a partial refund on a paid-out order? |
| Moderation and trust | A policy page and an email address; the operations team reviews what is reported | Verification flows, a moderation queue with automated first-pass triage, appeals, audit trail, and a suspension model with consequences for live orders | When a listing is removed at 11pm, what happens to the 4 orders already on it? |
| Mobile footprint | A responsive web app on both sides | Native iOS and Android for at least the seller side, with background behaviour, push, offline tolerance and store review cycles | Which side needs the phone to do something while the app is closed? |
| Admin console | Direct database access and a handful of internal scripts | A real internal product: search across every entity, impersonation, manual overrides with reasons, dispute handling, refunds, payout corrections, audit logging | Who fixes a broken order at 6pm on a Friday, and with what? |
The last row is the one most briefs forget entirely, and it is the axis with the widest spread. Internal tooling is unglamorous, invisible to the market, and the single largest determinant of how much software an operator needs — a point made in full in what a managed marketplace operator absorbs. If your model is managed rather than open, a proposal that treats the console as an afterthought has not understood the business.
What is left once the axes line up
After the sheet is filled the remaining spread usually has 4 causes, in this order of frequency.
- An unstated assumption about your existing systems. One responder assumed your current data comes out cleanly; another assumed it has to be reconstructed. That difference is settled by the export test in prove you can get your data out before you commit, and it is worth running before you ask anyone to re-quote.
- A different reading of the word MVP. To one responder it means the smallest thing that proves demand exists; to another it means the smallest thing that could carry real money and real sellers. Both are defensible, and they are not the same product. Our own definition sits in MVP and product builds, and any brief using the word should define it in a sentence.
- Integration surface counted or not counted. Notifications are the usual offender: one proposal prices a push integration, another prices a delivery-guaranteed state channel, because push is a hint rather than a transport for order state and only one responder knew that.
- Design treated as included or excluded. This is easy to spot and easy to normalise, and it is worth handling last so it does not distract from the 5 axes.
The middle number is the worst available default
Choosing the middle proposal feels like risk management and is the opposite. You are not buying the middle amount of software; you are buying one responder's specific interpretation of an ambiguous brief, chosen because it happened to land between two others. That interpretation was never written down as a scope, was never agreed, and is not what the other 2 responders were describing.
You cannot average three answers to three different questions and get an answer to yours.
Re-brief once, then re-quote against one scope
- Decide the 5 axes yourself, in writing, one paragraph each. This is your decision, not a supplier's, and it is the moment the project becomes estimable. The full pre-estimate list is in the decisions that have to exist before a marketplace can be estimated.
- State the surfaces explicitly, by name and by side of the market, and say which are in the first release and which are later.
- Name every integration and mark it in or out. For anything you cannot name yet, describe the behaviour you need and label it an assumption to be priced separately.
- Ask for the response in a fixed shape: one section per axis, a surface list, an assumption register, and anything explicitly excluded. A proposal that cannot be read in that shape is not a proposal you can compare.
- Send the same document to the same 3 responders. Re-quoting against a fixed scope is a small ask, and a responder unwilling to do it has told you something useful.
Expect the second round to be tighter and to disagree less. Where it still disagrees, the disagreement is now about approach rather than about what is being built, which is the argument you actually want to have. If the exercise also reveals that the first release is larger than the business can wait for, the sequencing question is a separate one, and a service marketplace cut into three releases works through one way of doing it.
One last thing the sheet often exposes: a responder proposing a hosted platform where another proposed a custom build. That is not variance, it is a different strategy, and it should be decided before anyone estimates anything — see hosted platform or custom build, and the five questions that settle it. The rest of this silo sits under build versus buy, platform choice and scoping, and the way we scope this work is described in our marketplace and two-sided platform practice.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
Why do marketplace development quotes differ so much for the same brief?
Because a marketplace brief that does not fix the seller surface, the money model, the moderation posture, the mobile footprint and the admin console leaves 5 decisions to the reader, and each responder answers them in the direction their team is strongest. The result is 3 proposals for 3 different products. Line them up on those 5 axes and most of the spread turns out to be scope rather than margin.
Should I ask the responders to explain their differences?
Ask them what they assumed, not why they differ. Asking about the difference invites each one to argue against a document they have not seen and cannot fairly critique. Asking each to state their assumptions on the 5 axes gets you comparable answers, and it gets them from a position where they are describing their own work rather than defending it.
Is the highest proposal usually the most thorough one?
Not reliably, and treating it that way is as lazy as taking the middle. A larger number can mean a wider surface count, a heavier read of the money model, an included design phase, or simply a responder who has been burnt by an under-specified marketplace before and is protecting themselves. The sheet tells you which of those it is; the number on its own does not.
What is the single question that separates a serious proposal from a thin one?
Ask what happens to orders that are already in flight when something goes wrong — a listing is removed, a seller is suspended, a payment is disputed after payout. Every marketplace eventually runs on the answers to those questions, and they sit across the transaction model, the money flow and the admin console at once. A responder who has built one will answer immediately; a responder who has not will describe a policy.
- proposals
- scoping
- procurement
- marketplace build
The work behind this page
Builds from our portfolio that this page draws on.
Low Latency Food Ordering Platform
Unified events operations platform: vendor management, order tracking, payments, automated settlements.
MarketplaceQuoteForge
An AI CPQ and proposal platform that builds enterprise quotes from your catalog, guards every discount against the margin floor, routes approvals, and generates the proposal.
Sales AIRead next
- Availability: a set of intervals, not a grid of day cellsAvailability is not a stored fact. It is the answer to a question, computed from recurring rules, exceptions and what has already been consumed — and a day-cell table is a cache of that answer.definition
- Inventory hold: the row that exists so the second buyer is refusedA hold is a record, not a screen state. It names one unit of supply, one claimant, one expiry and one reason — and while it lives, nothing else may overlap that unit.definition
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation