Anatomy of a B2B marketplace MVP: the 9 features that eat 80% of the budget

A B2B marketplace MVP gets priced like an e-commerce build and engineered like a fintech product, and the gap between those two numbers is where most founder budgets die. Before the aggregate, the anatomy: one quarter, thirteen weeks, inside the net-terms engine of the largest marketplace we work on.

Anatomy: one quarter of net-terms decisions at CREOATE scale

CREOATE is a cross-border B2B wholesale marketplace: $5M+ funded by Fuel Ventures, 800K+ orders processed lifetime, a catalogue past 1M+ SKUs from 6,500 brands, primary data store DynamoDB on AWS eu-west-2. It is positioned against Faire and Ankorstore, and its wedge against both is 90-day net terms, productised as Trade Direct. Retailers stock their shelves now and pay in 90 days; brands get paid on schedule; the marketplace carries the gap in between. The engineering behind that gap is the subject of our B2B marketplace development practice, and it is the best single lens we know for explaining where marketplace budgets actually go.

The credit engine does not run alone. Our practice page lists eight capability areas that have to ship together on a marketplace of this kind: catalogue ingestion and normalisation, KYC and identity orchestration, the net-terms and credit engine, marketplace payments and payouts, cross-border logistics and duty, fraud and supplier vetting, the storefront and buyer UX, and the operator tooling the marketplace actually runs on. At CREOATE scale the catalogue side alone is a serious system: 6,500 brands averaging around 150 SKUs each arrive as CSVs, Shopify exports, manual entry, and partner APIs, and every one of them has to be normalised, deduplicated, and made searchable before any credit decision matters. But the credit engine is where the unit economics live, so that is where we will spend the quarter.

So watch what one quarter of net-terms operation at that scale asks of the software. Strip the storefront away and the engine is making four kinds of decisions, continuously, for thirteen weeks.

Decision one, the limit. Every retailer who applies for terms needs a credit limit before their first order ships. The inputs are the KYB and KYC state, the business entity checks, the order history if any exists, and the category risk of what they buy. The limit has to be assigned programmatically, because no credit desk can review every application at marketplace volume, and it has to be overridable, because the operator team will always know things the model does not. Building the state machine that holds an application between automated verdict and human override is unglamorous work that no pitch deck ever mentions.

Decision two, the order.At checkout the engine answers one question in milliseconds: does this order fit inside the buyer's remaining exposure? That means the ledger of open receivables has to be correct in real time, not reconciled nightly, because an order approved against stale exposure is an unsecured loan the marketplace never chose to make. This is the point where the credit engine stops being a finance spreadsheet and becomes a low-latency service on the order path.

Decision three, the chase. Terms mature. A dunning ladder walks each invoice from a polite nudge through payment links to a collections posture, and every message has to remember that the debtor is also the customer the marketplace spent money acquiring. The sequencing, the templates, the retry logic, and the operator queue for accounts that stall are all software, and all of it has to reconcile against the payment processor daily.

Decision four, the write-off. Some fraction of the book will not pay. Each case gets a review: fraud, which feeds the vetting rules, or distress, which feeds the limit model. The losses then roll up into the one number that disciplines the other three decisions. The rule we carry from the CREOATE work is blunt: a “default rate above 3 to 4% breaks the marketplace”, because wholesale margins cannot absorb more. That sentence is the reason the credit engine gets more engineering hours than the storefront.

Threaded through all four decisions is the operator console, because every automated verdict needs a place where a human can see it, question it, and reverse it. The credit desk view, the dunning queue, the write-off review screen: none of it is customer-facing, none of it demos well, and the marketplace cannot run a single day without it. When we say the trust layer eats the budget, a meaningful slice of that is simply giving the operations team eyes.

One quarter of that, at 800K-orders-lifetime scale, is tens of thousands of automated credit decisions and a steady drip of human overrides, chases, and write-off reviews. And here is the budget point: that entire engine is one line item out of nine. Across the marketplace engagements we have shipped and audited, it averages 14% of the MVP budget, and eight other features behave exactly the same way, invisible in the pitch deck, dominant in the invoice. The aggregate below.

The aggregate: 11 engagements, nine features, one budget

We have shipped or audited 11 B2B marketplace and marketplace-adjacent builds over the last four years: new MVPs, replatforms off multi-vendor WooCommerce and Magento setups that could not carry the trust layer, and rescue engagements on marketplaces that launched storefront-first and stalled. Normalising those engagements to a common MVP scope produces a per-feature cost distribution that is remarkably stable across verticals, which is why we are comfortable publishing it as a planning tool.

The reason to account per feature rather than per project is that total-cost quotes hide the argument. Two agencies can both quote $150k for the same marketplace and be describing wildly different products: one has priced a storefront with a payments plugin, the other has priced the trust layer. A per-feature breakdown makes the difference visible before the contract is signed, which is worth more to a founder than the number itself.

Three computed metrics run through the findings: Feature Cost Share (FCS), Net-Terms Risk Exposure (NRE), and Time To First Transaction (TTFT).

Methodology

Per-feature engineering hours were aggregated from 11 marketplace engagements (2022 to 2026): 5 ground-up MVP builds, 3 replatforms, 3 rescue audits with enough commit and time-log history to reconstruct hours. Sources are Linear and Jira time logs, invoice line items, and repository history. Each engagement was normalised to a first-transaction MVP scope: buyer storefront, seller onboarding, catalogue ingestion, KYC, marketplace payments with splits and payouts, net terms in at least manual-desk form, search, RFQ where the vertical required it, a fraud baseline, and the operator console. Hours are medians across the sample; money figures use blended UK and India rates. Work outside that scope (native apps, growth engineering, post-launch retainers) is excluded. All aggregate figures are anonymised and published with client consent; CREOATE references are limited to facts already public in our case study material.

Finding 1: nine features absorb 80% of the budget

The nine features sum to exactly 80% of the median budget; the storefront and the project scaffolding split the remaining 20%. That inversion is the finding. Founders arrive with a storefront prototype and a budget sized to it, then discover the prototype covered 12% of the work. It also reconciles cleanly with the claim on our service page that real B2B marketplaces are 60% trust infrastructure: the six trust-adjacent lines (credit, payments, KYC, fraud, cross-border, seller onboarding) sum to 60% on the nose.

In money: 2,600 median hours lands between $130k and $190k at our blended rates, before the discovery phase. That is above the general MVP band in our MVP cost study across 31 engagements, and the delta is entirely the trust layer: a SaaS MVP does not carry a receivables book, a KYC pipeline, or a payout engine.

The medians also hide spread worth planning around. Net-terms FCS ranged from 9% on builds that launched with a manual credit desk to 19% where automated decisioning was launch scope. Search ranged from 5% on a four-figure catalogue to 12% where the SKU count ran to six figures. Cross-border was near zero for the two single-market builds and 11% for the engagements shipping into the EU and US from day one. The one number that barely moved was the storefront: 10 to 14% on every engagement in the sample, however ambitious the designs were.

Finding 2: the credit engine is a small fintech product

Notice what the hours cluster around: decisioning, dunning, and reconciliation, not the credit maths itself. A workable scoring model for a young marketplace is rules plus a handful of signals; the expensive part is the machinery around it. Dunning and reconciliation in particular are the same machinery that subscription billing needs, which is why our Stripe billing integration work and our marketplace work share so much code: retry ladders, idempotent state transitions, and a daily reconciliation job against processor balance transactions.

The honest MVP version of this feature is a manual credit desk behind a correct ledger. Assign limits by hand for the first hundred buyers, but build the exposure check and the ledger properly from day one, because retrofitting correctness into a receivables book that has been drifting for six months is the single most expensive rescue pattern in our sample.

The other eight line items, briefly

The credit engine got the anatomy treatment because it is the largest line, but each of the remaining eight hides the same pattern: a simple pitch-deck sentence sitting on top of weeks of state machines, queues, and reconciliation. What the hours actually contain, feature by feature.

Marketplace payments on Stripe Connect, 312 hours. Connect gives you the rails; it does not give you your commission engine, your payout schedule, or your ledger. The hours go into split calculation across mixed-seller carts, multi-currency settlement, refunds that unwind a split correctly, dispute and chargeback handling, and the daily reconciliation job that proves the ledger against processor balance transactions. This is also where webhook reliability stops being optional: a missed payout event is money sitting in the wrong place.

KYC orchestration, 260 hours. The verification verdict itself is rented from an identity provider. The custom work is the orchestration around it: multi-provider routing with fallback, document re-collection when a check expires, business entity verification, AML and sanctions screening, and the review queue where an operator can approve, reject, or escalate. The application state machine has more states than most teams expect, because real businesses arrive with expired documents, mismatched directors, and trading names that match nothing.

Seller onboarding, 234 hours.The funnel from application to first live listing: vetting checks, payout account collection, catalogue mapping from whatever format the seller has, and the drop-off instrumentation that tells you where suppliers stall. Nothing meaningful is rentable here because the funnel is the marketplace's supply strategy expressed as software, and every vertical's version is different.

Search at SKU scale, 208 hours. Database search dies quietly somewhere in the tens of thousands of SKUs. The hours buy an Algolia or Elastic tier, the indexing pipeline that keeps it in sync with the catalogue, and relevance tuning for trade attributes buyers actually filter on: case pack, minimum order quantity, lead time, margin. On the larger catalogues, embedding-based relevance joins the stack.

Cross-border logistics and duty, 208 hours.Carrier callbacks, customs documentation, duty and VAT calculation at quote time rather than as a surprise at delivery, and returns routing that crosses a border in reverse. The calculation APIs are rentable; wiring their answers into checkout, invoicing, and the seller's paperwork is not.

RFQ flows, 182 hours. Quote-driven buying is a negotiation state machine: request, counter, expiry, acceptance, and the conversion of an agreed quote into an order at non-catalogue pricing. It touches permissions, notifications, and pricing integrity everywhere, which is why it has the highest custom share in Chart 3 and why platform tools treat it as an afterthought.

Fraud and anti-counterfeit, 182 hours. Behavioural signals on buyer accounts, listing content scanning on the supply side, brand-protection workflows, and the review queues where humans confirm what the rules suspect. At MVP stage this is mostly plumbing for evidence: the losses that eventually train better rules have to be captured cleanly from day one.

Bulk pricing, 130 hours. The smallest of the nine and the most invasive per hour: price breaks, MOQs, and per-buyer negotiated rates have to hold consistently across search results, product pages, carts, quotes, and invoices, and every bulk price interacts with the exposure check in the credit engine. Small feature, long reach.

Finding 3: what you can rent, what you must build

The pattern: vendors sell verdicts and rails, and you still build the orchestration. A KYC provider will verify a document in seconds; it will not hold your application state machine, your review queue, or your multi-provider fallback. Stripe Connect is the closest thing to a genuine shortcut in the whole table, and even there more than 300 hours went into splits, commission logic, payout reconciliation, and webhook reliability. (The webhook half of that is its own discipline; the patterns are in our Stripe webhooks end-to-end guide.)

The same logic answers the platform question. Tools like Sharetribe and Mirakl compress the rentable rows brilliantly, but the rows with 90%+ custom share, RFQ and seller onboarding, are precisely where a B2B marketplace differentiates. If your vertical needs net terms or quote-driven buying, the platform tool does not remove the budget, it defers it and adds a migration.

The net-terms row deserves its own note. Renting the capital through a BNPL or trade-credit partner is a real option and several of our engagements took it: the partner underwrites the buyer and carries the default risk in exchange for a slice of the margin. What surprises founders is the custom share that remains at 70% anyway. The partner decides whether a buyer gets credit; your software still owns the exposure a buyer has already used, the ledger the finance team closes against, and the checkout experience that makes terms feel native rather than like a redirect to someone else's product. Renting the balance sheet does not rent the engineering.

Finding 4: TTFT punishes storefront-first sequencing

Median TTFT across the full sample is 21 weeks. The eight-week penalty for storefront-first sequencing is not because the storefront was wasted work; it is because the trust layer changes the data model underneath it. Payouts change the order schema, KYC changes the account schema, and exposure checks change the checkout path, so a storefront built before those decisions gets rebuilt around them. The teams that decided their architecture early, including the tenancy and isolation questions we mapped in the multi-tenant architecture cost study, spent their rework budget once instead of three times.

Two of the three rescue audits in the sample were storefront-first builds that had reached a polished demo and stalled short of a first transaction, one for five months. In both, the credit and payout retrofit forced schema migrations through live order data, which is the most nervous kind of engineering there is. The lesson is not that storefronts are wrong; it is that on a marketplace the storefront is the roof, and roofs go on last.

How we measure marketplace MVP cost

1. Feature Cost Share (FCS)

FCS = Feature engineering hours / Total MVP engineering hours

The planning metric. Multiply your quoted budget by the FCS table and you get a sanity check per feature: a proposal that prices the credit engine below the storefront is describing a different product than a net-terms marketplace.

2. Net-Terms Risk Exposure (NRE)

NRE = Open net-terms receivables x Expected default rate

The number the credit engine exists to control. A marketplace with $400k of open receivables at an expected 3% default carries $12k of NRE per cycle, which wholesale margin can absorb; at 5% the same book costs $20k and the model is underwater. This is the CREOATE ceiling expressed as a formula, and it is why NRE belongs on the operator dashboard from week one, even when the credit desk is manual.

3. Time To First Transaction (TTFT)

TTFT = Weeks from kickoff to first completed transaction between unrelated buyer and seller

The honest launch metric. A marketplace is not live when the storefront deploys; it is live when a stranger pays a stranger through it and the money lands correctly. Median 21 weeks in our sample, range 16 to 31. Founder-and-friend test transactions do not count, because they skip precisely the machinery, KYC, credit, payouts, that the budget went into. Plan fundraising milestones around TTFT rather than launch dates and the conversation with investors gets considerably easier.

The 2026 backdrop: why this maths suddenly matters

The reason we are publishing the breakdown now is that the market has stopped being a niche. B2B e-commerce reaches roughly $28 trillion in 2026 on Grand View Research's sizing, and the buying behaviour underneath it has shifted: 59% of B2B buyers now do over a quarter of their purchasing on marketplaces rather than through reps and price lists. The supply side has responded in kind: vertical B2B marketplaces grew from roughly 75 to more than 750 in five years, which means most founders reading this are not creating a category, they are racing incumbents to liquidity in one.

The stat with the most direct budget consequence is the quietest one: 94% of business buyers use AI at some point during purchasing. A buyer's agent comparing suppliers does not admire your hero section; it reads structured product data, stock, lead times, and terms. That pushes budget further toward the unglamorous rows of Chart 1, catalogue normalisation, search, machine-readable pricing, and away from the storefront, which is exactly the direction our FCS data already points.

None of this argues for building more features. It argues for building the right 80% sooner, because a crowded vertical is a race to liquidity: the marketplace that can verify a seller, extend terms, and settle a payout cleanly wins the suppliers, and the suppliers bring the buyers. In a field that went from 75 players to 750 in five years, an MVP that spends its first six months polishing the 12% is donating its window to a competitor that spent them on the rails.

The build sequence we recommend

Weeks 1 to 4: paid discovery

We run three to four weeks of paid discovery first on every marketplace engagement: map the trust layer, the credit model, the catalogue shape, and the operator workflows, and leave with a system design and a phased plan whether or not the build continues with us. Discovery is where the nine-feature list gets cut to the launch-blocking subset for your vertical, which is the highest-leverage budget decision in the whole project.

Phase one: rails before credit

KYC orchestration, marketplace payments, seller onboarding, and search come first, because every later feature writes to the schemas these define. This phase looks and runs like a serious SaaS web application build: auth, roles, the operator console, and the storefront growing alongside the rails rather than ahead of them. Payments land on Stripe Connect with the splits, payout schedule, and webhook reliability treated as first-class scope, not integration cleanup.

Phase two: credit, RFQ, and the scale features

Net terms starts as a manual desk on a correct ledger, then automates decisioning as volume proves the model, with the dunning and reconciliation machinery shared with the billing integration layer. RFQ and bulk pricing follow observed buyer behaviour rather than assumptions, and fraud tooling graduates from rules plus review to signals as the loss data accumulates. Sequenced this way, the 80% is spent in the order the risk arrives, which is what the TTFT data in Chart 4 rewards.

A note on what to cut when the budget will not stretch. Cut automation, not correctness. A manual credit desk, a human fraud queue, and an operator approving payouts by hand are all fine at MVP volume, and each converts engineering hours into headcount you already have. What cannot be cut is the data model those humans work on: the ledger, the exposure record, the KYC state. Every stalled marketplace in our rescue sample had cut in the opposite order, automating the storefront while the financial truth lived in a spreadsheet.

Limitations

Eleven engagements is a small sample, and it reflects the founders who came to us, which biases toward net-terms and cross-border verticals where the trust layer is heaviest. Hours normalisation across differently-scoped engagements involves judgement, especially for the three rescue audits where hours were reconstructed from history. Money bands use blended UK and India rates and will not match Bay Area quotes. CREOATE figures are limited to publicly stated facts and are not drawn from the aggregate dataset. Percentages are medians and directional; your vertical will move individual rows by a few points, though in our experience the 80/20 shape survives every reweighting we have tried.

The takeaway survives the caveats. A B2B marketplace MVP is nine unglamorous features wearing a storefront, and the budget conversation goes better when everyone at the table has seen the FCS table before the first design review. Price the credit engine like the fintech product it is, sequence the rails before the roof, and hold the build to TTFT rather than a launch date, and the 80% stops being a surprise and starts being a plan.

Pair this breakdown with the architecture and cost studies that sit underneath it:

And the engagements that ship the nine features, from the trust layer to the application shell around it: