Marketplace and Two-Sided Platform Engineering

Not one we can present as a named consumer two-sided marketplace, and we would rather say that than blur it. The closest real thing we have shipped is a multi-vendor ordering and settlement platform: vendor onboarding and management, orders, payments through Stripe, configurable commission rates per vendor and category, multi-currency and tax computation, automated settlement calculations, role-based access across five roles, and a full audit trail. That is genuinely the supply-side and money-movement half of a marketplace, in production. What it is not is an open market with consumer demand, ranking, and trust-and-safety at public scale. If a named marketplace reference is a hard requirement for your procurement, we are not the right studio for this engagement yet.

No — and treat any studio that says yes casually as a red flag. We hold no money-transmitter or payments licence and never take custody of funds. What almost everyone means by marketplace escrow is delayed payout: the charge is taken through the platform's payment provider, the money sits with that provider, and the transfer to the seller is released on a condition or a timer. Stripe Connect supports this with separate charges and transfers; Adyen for Platforms and Razorpay Route have equivalents. We build against those rails, and the licence, the KYC obligation and the custody all stay with the provider.

Because you are building two products, an admin console and a money flow, not one app with a second login. Each side has its own onboarding, notifications, empty states and failure modes, and the things that stretch a timeline are invisible in a demo: refund and partial-refund edge cases, cancellation and dispute states, moderation tooling, and the reconciliation everyone discovers in month three. The parts founders assume are hard — listing pages, search UI, profiles — are usually the fast half. We scope against those axes and quote per scope.

Start on a platform when your market is a familiar shape and your edge is supply, brand or operations rather than mechanics — you will reach a live market far sooner and learn things no architecture decision can tell you. Build custom when the thing that makes you a business is the transaction mechanic itself: matching, availability, dynamic pricing, verification, multi-party payouts. That is the layer platforms hold most tightly. A useful test before you commit: write down the five things your platform must do that a competitor's cannot. If none of them touch the transaction mechanic, do not build yet. We are happy to say 'stay where you are for another two quarters' at the scoping call.

It can handle the first pass and the triage, not the final call on the contested cases. In practice that means a model scores and routes every listing, message or report — auto-approving the clearly fine, auto-blocking a narrow set of unambiguous violations, and pushing everything ambiguous to a human queue ordered by risk — plus an appeals path and an audit trail of who decided what. The same applies to listing quality, where AI is genuinely strong: enriching thin descriptions, normalising categories and attributes, and catching duplicates across sellers. We hold no certifications and we are not a trust-and-safety compliance vendor; what we build is the engineering layer your policy runs on, and your policy has to exist first.

We build the data capture and reporting plumbing; we do not give tax or legal advice, and your counsel or accountant defines what applies to you. The practical point for a build is that these regimes are data-model requirements long before they are filing requirements — verified seller identity, tax identifiers, per-seller gross consideration by period, fees and commission withheld, and an immutable record of it all. Retrofitting that into a schema that never recorded it is one of the more expensive migrations in this space, so it is worth deciding early even if the thresholds do not catch you yet.

No. We work Monday to Friday, IST business hours, and we do not offer 24/7 support — so for a platform that transacts on a Saturday night, that has to be designed for rather than staffed around. In practice it means idempotent and retry-safe payment and order paths, queues that drain rather than drop, alerting and runbooks your own on-call can act on, and admin tooling that lets a non-engineer refund, cancel or unblock without a deploy. We would rather build a system that degrades safely without us than promise a pager we do not carry.