Vendor onboarding, search and matching, split payments and payouts, reviews and disputes — modelled as the state machine it actually is, so it stays debuggable when volume arrives. SolarSathi is live and in the work below.
A marketplace is a buyer product and a seller product that happen to share a database. They have different screens, different incentives and different failure modes, and scoping them as one thing is the most common reason marketplace builds overrun.
Enquiry, response, acceptance, fulfilment, payment, review — every transition needs a defined state, a notification and an audit trail. Modelled explicitly, this stays debuggable at volume. Left implicit, it becomes unmaintainable within months.
Taking payment is easy. Holding it, splitting it, paying out on a schedule, handling refunds when one side has already been paid, and staying on the right side of the rules — that is the work, and it gets scoped explicitly rather than assumed.
Search, filters and ranking that surface the right supplier rather than the loudest one.
Marketplace payments with commission, escrow-style holds and scheduled payouts via Stripe Connect.
Onboarding, document checks and approval flows so buyers can trust who they are dealing with.
Ratings tied to completed transactions, so the signal cannot be gamed by people who never bought anything.
Conversations that stay on the platform, with a record when something is disputed.
The admin view your own team needs to approve, intervene, refund and see what is happening.
Marketplaces fail at the cold start, not at the code. An empty platform is worthless to both sides at once, and no amount of engineering fixes that — it is solved by manually recruiting one side, launching somewhere narrow enough to look full, and brokering the first transactions by hand while the product does the parts it can.
That changes what we build. The admin tooling that lets your team intervene manually is not a nice-to-have you add later; for the first months it is the product. Category and region are configuration rather than assumptions baked into the schema, so you can launch in one and expand without a rewrite. And the first version deliberately leaves self-serve automation out, because automating a process you have not run manually yet is how you automate the wrong one.
If you have not yet recruited any supply, that is the work to do before commissioning a build — and we will say so on the call rather than after the invoice.
Frontend web platform for Nullzec, an enterprise browser-isolation company. WizCodes built the client-facing web application and dashboard UI — the interface through which the product is configured and monitored.
Full-stack web platform built for a Spanish client with custom business logic and a responsive, performant frontend.
B2B solar vendor discovery and procurement marketplace for the Indian market. Multi-vendor listings, quote requests, and vendor profile pages.
Honestly: mostly you do not solve it with software, and any developer who implies otherwise is not worth hiring. A marketplace with no sellers is useless to buyers and vice versa, and that is a business problem that gets solved by manually recruiting one side first. What software can do is make the empty side less visible and the manual work possible — seeding supply so the platform is never blank, launching in one narrow category or one city rather than everywhere, and giving your team admin tooling to broker the first few hundred transactions by hand while it looks automatic to users. Almost every marketplace that worked did this. Build for the first fifty transactions being partly manual, not for the ten thousandth being automatic.
Usually through a marketplace payment provider — Stripe Connect is the common choice — which handles the part you genuinely do not want to build. Sellers are onboarded as connected accounts with their own identity verification, so you are not holding their banking details or becoming a money transmitter. A payment can be split at the point of capture, with your commission separated automatically, and funds can be held until the transaction is confirmed complete rather than released immediately. Payouts run on a schedule you define. The decisions that actually need making are yours rather than technical: when money is captured, when it is released, what happens to your commission in a refund, and who bears the cost when a payment is disputed after a payout. Those get agreed during scoping because they are policy, not code.
You need a path for them from the start; you do not need it automated. Disputes are rare early and inevitable eventually, and the expensive mistake is having no defined process — an unhappy buyer, a seller already paid, and nobody with the ability to intervene. The minimum viable version is admin tooling that lets your team see the full transaction record, communicate with both sides, and issue a refund or adjust a payout manually. That covers you until volume justifies something more structured. What is genuinely worth building early is the record: messages, state transitions and timestamps kept on the platform, because a dispute you cannot reconstruct is one you will resolve badly and expensively.
Rarely. The pattern that works is to pick the harder side to acquire — usually supply — and get it on board before opening the other, often by recruiting them individually and giving them something of value even while the other side is thin. Launching narrow helps enormously: one city, one category, one vertical. A marketplace with forty suppliers in one category feels full, and the same forty spread across twenty categories feels abandoned, which is the same data producing opposite outcomes. Build the platform so that narrow launch is possible — categories and regions as configuration rather than hardcoded assumptions — and you can expand without a rewrite.
Yes, and for a marketplace it is close to essential, because the assumptions you are making about how the two sides behave are unusually likely to be wrong. A marketplace MVP typically means one narrow category, manual vendor onboarding instead of self-serve, payments taken but payouts handled manually by your team, and messaging over email rather than in-platform. That is a real, transacting marketplace at a fraction of the cost of the full platform, and it teaches you which of your assumptions were wrong before you have paid to build on them. SolarSathi launched close to this shape. The path from there is scoped as a second phase once real transactions have told you where the friction actually is.
The full engineering story of a shipped marketplace — the four-state quote workflow and event-driven notifications — is in the SolarSathi case study.