This is the first question almost every founder asks, and it is the hardest one to answer honestly in a single number. Anyone who quotes you a price before understanding your transaction model is either guessing or selling you a template.
What I can do is show you what the number is actually made of, so that when you get quotes — from me or from anyone else — you can tell which ones are real.
Cost does not scale with pages. It scales with surfaces and transactions.
A twenty-page brochure site and a five-page marketplace are not comparable projects. The marketplace is far more expensive, because a marketplace is not a website with a shopping cart. It is at minimum three products sharing one backend:
- The customer surface — browse, search, cart, checkout, order tracking
- The vendor surface — onboarding, catalogue, order queues, payouts
- The operations surface — approvals, disputes, commissions, reporting
Every additional surface is a full product with its own screens, permissions and edge cases. When a founder tells me "it's basically like Amazon but simpler", the honest translation is usually "three products, and I've only thought about one of them".
The second multiplier is transaction complexity. Ask yourself:
- Does one customer order ever need to split across several vendors?
- Do prices get negotiated, or are they fixed?
- Do you hold money before paying vendors out?
- Do refunds happen, and can they be partial?
- Are there commissions, and do they vary by category or vendor?
Every "yes" there adds real engineering, because each one touches money, and money has to be correct rather than approximately correct. On MONTRA, the B2B elevator parts platform, the order-routing and ledger work was the largest single part of the build — and it is also the part the client valued most, because it is what makes payouts defensible.
The five things that most affect your number
1. How many surfaces go live at launch
The cheapest real marketplace has two: a customer storefront and an operations console. Vendors are onboarded manually at first, by you, over a phone call. That is not a compromise — for your first twenty vendors it is genuinely faster than software.
Adding a self-serve vendor dashboard, native apps for two roles, and a partner portal can double or triple the build without changing the business model at all.
2. Whether you need native apps on day one
Usually you do not, for buyers. Often you do, for suppliers and drivers who work on their feet. Ajza ships three separate native apps — customer, supplier, rider — but the backend was designed so those could be added against the same API. That sequencing is a cost decision, not a technical one.
I've written about the trade-off in more detail in Flutter vs native for startup MVPs in MENA.
3. Payments and how money actually moves
Card payments through a regional gateway are the easy part. The expensive parts are the ones specific to this region:
- Cash on delivery still carries a large share of orders in both Egypt and Saudi Arabia, and it changes your order lifecycle: money arrives after fulfilment, not before.
- Wallets and store credit mean you are holding customer funds, which means you need a ledger, not a balance column.
- Vendor payouts mean commission rules, settlement runs and statements vendors can reconcile without calling you.
If your platform never holds money — vendors get paid directly and you invoice commission monthly — you have just removed one of the most expensive parts of the build. That is a legitimate strategy for a first version.
4. Arabic, properly
Arabic RTL is not a translation task. It affects the data model, the layout system, search normalisation, invoices, emails and SMS. Building both languages from the first screen costs a modest amount. Retrofitting Arabic onto an English-first product costs a lot more, and always at the worst possible moment. See Arabic RTL product design mistakes that hurt conversion.
5. Whether your data is already structured
If you arrive with an Excel export of 4,000 products with inconsistent naming and free-text compatibility notes, importing and normalising that is a real workstream. On parts platforms specifically, it is often the single most underestimated line item. It is also the one you can reduce most, by cleaning data before the build rather than during it.
The bands I actually work in
Rather than invent market averages, here are the ranges I quote from, published so you can self-select:
| Engagement | Typical shape |
|---|---|
| Under $5k | A premium landing page or lead-capture site. Not a marketplace. |
| $5k – $15k | A focused MVP: one core workflow, one or two surfaces, production deploy. |
| $15k – $40k | A real multi-sided platform: customer + vendor + admin, payments, one native app where it earns its place. |
| $40k+ | Multi-marketplace or multi-app platforms, ledgers, RFQ negotiation, several native surfaces. |
These are engagement bands for a single senior engineer, not agency rate cards. An agency covering the same scope typically carries account management and project management on top; you are paying for parallel capacity and process, which is worth it for some projects and pure overhead for others. I've laid out that comparison plainly on the solutions overview.
How to get a cheaper marketplace without getting a worse one
Three levers, in order of effectiveness:
- Cut surfaces, not quality. Launch with manual vendor onboarding. You will learn more from twenty vendors you spoke to personally than from a self-serve flow nobody uses yet.
- Cut transaction complexity. Fixed prices before negotiated ones. Single-vendor orders before split baskets. Add the complex flows once real orders prove you need them.
- Do not cut the data model. This is the one place where saving money now guarantees spending more later. Compatibility data, tenant isolation, and the ledger are all things that are cheap to build correctly and brutal to retrofit.
What I would not cut: Arabic support, a real deployment pipeline, and correct money handling. Those three are the difference between a platform that grows and one that gets rewritten in eighteen months.
Getting a number for your project
If you want a real answer rather than a range, the fastest path is to write down what you are building in a structured way. The Project Brief Generator walks you through eight questions and produces a document you can send to me or to anyone else you are getting quotes from — it takes about three minutes and runs entirely in your browser.
Or book a free 15-minute call and bring one thing: the workflow that hurts most today. That is usually enough to shape a first version and give you an honest ballpark.