Why is the range so wide?

Because two things called a marketplace can be completely different systems. A searchable directory where buyers find a vendor and then contact them directly sits at the bottom of the range. A platform that takes the payment, holds it, deducts a commission and pays vendors out sits at the top, and brings compliance obligations with it. The scoping conversation exists to work out which one you are actually asking for before anybody quotes.

Do I need to handle payments in version one?

Usually not, and skipping it is the single most effective way to get live inside a real budget. Letting buyers and vendors transact directly at first — with the platform earning through listing fees, featured placement or a subscription — removes the most expensive and most regulated component while you find out whether anybody wants the thing at all. Money can be routed through the platform later, once there is volume that justifies it.

How long before I have something real that people can use?

With scope cut deliberately, a directory with listings, search, vendor accounts and an admin approval queue is achievable inside the shorter end of the timeline. A full transactional marketplace with payouts is the longer end and is better delivered in phases with something usable at the end of each, rather than as one long build that shows nothing until it is finished.

Where do my first vendors come from?

That is your answer to give, and it is the question we will press on hardest during scoping. Marketplaces fail on supply far more often than on software. If you have an existing group, a list, a trade association or a business already sending people to these vendors, you have a real starting position. If the plan is that vendors will find the site once it exists, the build is not the risky part of your project.

Can you build it for the lower end of the range?

Sometimes, and the honest version of that answer starts by cutting the feature list rather than the quality. Listings, categories, proper search, vendor accounts and moderation fit in a small budget. Messaging, reviews, wallets, mobile apps and payouts do not fit in the same budget, and pretending otherwise produces a half-built version of all of them instead of a working version of some.

What stops fake or spam listings?

An approval queue before anything goes public, verification appropriate to what is being listed, and rate limits on account creation and posting. This is unglamorous and it is not optional — an open directory with no moderation fills with junk quickly, and a directory full of junk cannot be shown to the real vendors you are trying to recruit.

Web Development & Engineering

Directory and marketplace platform

Two sides, two journeys and a platform in the middle — scoped so the first version can launch before the budget is spent on payouts nobody is using yet.

From: $4,000–$30,000
Typical time: 2–5 months
Usually bought by: Founders

What this actually solves

Somebody has noticed a gap. Finding a reliable tradesperson in their city is difficult, or the good suppliers in an industry are scattered across a hundred phone numbers, or a trade that currently runs on a messaging group has outgrown it. The idea is to sit in the middle, introduce the two sides to each other, and take a share.

It is worth naming who is usually asking, because it changes how this work should be done. This is often a founder rather than the owner of an existing business — someone spending their own money on something that does not exist yet, with a fixed budget and expectations that have not yet met a build schedule. The most valuable thing they can be given is not enthusiasm. It is an honest estimate and a version-one scope small enough to reach real users while there is still money left.

The system underneath has two entirely separate journeys. The vendor signs up, builds a profile, publishes listings, manages enquiries or orders and, in a transactional model, tracks what they are owed. The buyer searches, filters, compares, and either contacts or buys. Between them sits the platform's own machinery — search, categories, moderation, reviews, messaging, and if money moves through it, payment splitting and payouts. And behind all of that is an admin panel that is genuinely a project in its own right, which is where first estimates most often go wrong.

What we do, and in what order

Scope against the budget before anything is designed. The full idea gets estimated honestly, and if it does not fit, the smallest version that can attract real users on both sides is defined instead. This is where features get postponed on purpose — messaging, reviews, wallets and in-platform payment are the usual candidates. The supply-side question is asked directly here — how many vendors will exist in launch week, and where are they now — and the answer is written into the plan. Three to five days.
Model the two sides and the listing structure. Accounts, roles and permissions for vendors, buyers and administrators. Then the listing itself — the fields, the categories and the attributes that people will actually filter on, which is a decision that is painful to change once vendors have entered data against it. Getting the category and attribute model right early is worth more than almost anything else at this stage. One to two weeks.
Build the vendor side and the moderation queue. Registration, profile, listing creation with images, editing, and the vendor's own view of enquiries or orders. On the platform side, an approval queue so nothing reaches the public until a human has passed it, plus rate limits and basic verification. Moderation is built at the same time as publishing rather than added after the first wave of spam. Two to three weeks.
Build search and browse properly. Faceted filtering, sorting, location handling where relevant, and typo tolerance. Dedicated search infrastructure such as Algolia or Typesense is used rather than pattern matching in the database, because database text search stops being usable as the catalogue grows and rewriting it later means rebuilding the most-used screen on the site. One to two weeks.
Add transactions and payouts only if version one needs them. Where money does flow through the platform, this means connected vendor accounts, identity and bank verification for each vendor, splitting each payment between platform and vendor, payout schedules, refunds and dispute handling. It is the heaviest component and it carries regulatory obligations that vary by country. Three to six weeks when included.
Load real data, then test the platform as each role. Real vendors and real listings rather than placeholder rows, because the layout and the filters only reveal their problems against genuine content. Then the whole thing walked through as a vendor, as a buyer and as an administrator, including the cases nobody enjoys — a vendor deleting a listing that has live enquiries against it, a buyer reporting a listing, a suspended account. One to two weeks.

What moves the price

The range is $4,000–$30,000 over 2–5 months, and one factor dominates all the others.

Whether money passes through the platform. A directory where buyers find a vendor and then deal with them directly sits in the lower part of the range. Add payment collection, commission splitting and vendor payouts and you have added identity verification, bank account handling, refunds, disputes and a set of financial regulations that differ by jurisdiction. This one decision moves the price more than every other feature combined.

How much of the social layer is included. In-platform messaging, reviews and ratings, notifications and vendor reputation are each substantial pieces of work with moderation consequences attached. They feel essential in a planning meeting and are frequently better delivered once there is enough activity for them to be worth moderating.

How much of the platform the administrator must control. The admin panel scales with how much you want to change without a developer — categories, featured placement, commission rates, vendor tiers, promotional rules. Each of those is a real interface, and collectively they are often a third of the build.

What usually goes wrong

The supply side is treated as somebody else's problem. This is not a coding failure and it is the one that kills marketplaces. Vendors will not join because there are no buyers, and buyers will not come because there are no vendors, so the platform launches into silence. Nothing in the plan covered it, and because the only tangible thing in the project is the website, the website gets blamed. The defence is asking during scoping how many vendors will be live in the first week and where they are being recruited from, and putting in writing that supply and marketing sit with you.

Payouts are built for version one when nothing is being sold yet. Connected accounts, verification, splits and payout scheduling can consume a large share of a first budget, and they deliver nothing at all until there is transaction volume. Launching with vendors and buyers transacting directly, while the platform earns through listing fees or featured placement, keeps the money for the parts that decide whether anybody uses the thing.

Search is left as a database query. Listings are matched with a simple pattern search because it works fine against the fifty rows loaded during development. Then the catalogue grows, filtering across several attributes at once gets slow, misspelt searches return nothing, and results come back in an order that makes no sense to a buyer. Search is the screen buyers spend all their time on, and replacing it after launch means rebuilding the centre of the product while it is live.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

Why is the range so wide?: Because two things called a marketplace can be completely different systems. A searchable directory where buyers find a vendor and then contact them directly sits at the bottom of the range. A platform that takes the payment, holds it, deducts a commission and pays vendors out sits at the top, and brings compliance obligations with it. The scoping conversation exists to work out which one you are actually asking for before anybody quotes.
Do I need to handle payments in version one?: Usually not, and skipping it is the single most effective way to get live inside a real budget. Letting buyers and vendors transact directly at first — with the platform earning through listing fees, featured placement or a subscription — removes the most expensive and most regulated component while you find out whether anybody wants the thing at all. Money can be routed through the platform later, once there is volume that justifies it.
How long before I have something real that people can use?: With scope cut deliberately, a directory with listings, search, vendor accounts and an admin approval queue is achievable inside the shorter end of the timeline. A full transactional marketplace with payouts is the longer end and is better delivered in phases with something usable at the end of each, rather than as one long build that shows nothing until it is finished.
Where do my first vendors come from?: That is your answer to give, and it is the question we will press on hardest during scoping. Marketplaces fail on supply far more often than on software. If you have an existing group, a list, a trade association or a business already sending people to these vendors, you have a real starting position. If the plan is that vendors will find the site once it exists, the build is not the risky part of your project.
Can you build it for the lower end of the range?: Sometimes, and the honest version of that answer starts by cutting the feature list rather than the quality. Listings, categories, proper search, vendor accounts and moderation fit in a small budget. Messaging, reviews, wallets, mobile apps and payouts do not fit in the same budget, and pretending otherwise produces a half-built version of all of them instead of a working version of some.
What stops fake or spam listings?: An approval queue before anything goes public, verification appropriate to what is being listed, and rate limits on account creation and posting. This is unglamorous and it is not optional — an open directory with no moderation fills with junk quickly, and a directory full of junk cannot be shown to the real vendors you are trying to recruit.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Directory / marketplace platform All Web Development & Engineering services