Building a Multi-Vendor Platform: VantyGo Architecture

If you are a CTO or an agency weighing up a multi-vendor platform, you do not need a tour of our repositories. You need to know which decisions carry the weight, which ones we would make again and where the traps are. This post covers VantyGo, our own local-commerce platform, at product level. It is live on the web at vantygo.co.il, and we operate it, so the choices below have been tested by running them rather than drawing them.

One codebase for web and mobile

The front end is a single React and TypeScript codebase built with Vite. It is served as a web app, and the same code is wrapped with Capacitor to produce iOS and Android builds. We chose this because a platform like this has several surfaces (customer, vendor, admin) and maintaining separate web, iOS and Android implementations of each would multiply every bug and every feature by three.

The trade-off is honest and worth stating. A wrapped web app is not a fully native app, and you accept the constraints that come with it. For ordering, browsing, booking and dashboards, we think the trade is clearly worth it. For something that depends heavily on device-specific behaviour, you would want to scope native work explicitly. Today VantyGo is web-only for customers; the iOS and Android builds exist and are in testing, and they are not in the App Store or Google Play.

A backend built from small services on AWS

The backend services run on Next.js, deployed on AWS with Lambda. That gives us compute that scales with demand and costs close to nothing when it is quiet, which matters for a platform whose traffic follows meal times and opening hours rather than a flat line. The data layer is a Postgres-compatible database, so the team works with familiar relational modelling and tooling rather than a niche query model.

We deliberately avoided a pile of tightly coupled services that all need to be up for an order to go through. Each piece has one job, and the boundaries between them are the part we spend the most design time on. When a client asks us what makes a platform like this hold up as it grows, this is usually the answer: not any single technology, but how clearly each part knows what it is responsible for, and how little it needs to know about the rest.

Queues and events for order and vendor workflows

An order is not one action. It is a chain: the customer places it, the vendor is told, the vendor accepts or declines, payment state is recorded, delivery is arranged, the customer is updated. If all of that happens inside a single web request, one slow step makes the whole checkout feel broken.

So we split it. Queues (SQS) hold work that must happen reliably but not instantly, and events (EventBridge) announce that something has happened so other parts of the system can react without the sender knowing who is listening. A failed step can be retried without the customer placing the order again, and a new reaction to an order, such as a notification, can be added without rewriting checkout.

The same pattern covers vendor workflows. When a vendor is approved or changes something, other parts of the system hear about it as an event instead of being called directly. The cost is real: asynchronous systems are harder to reason about and to debug, and you need to design for steps arriving late or twice. We pay that cost because the alternative is a checkout that fails whenever a downstream step is slow.

Vendors, catalogues and routing kept separate

The most useful structural decision in a multi-vendor platform is also the least visible: do not let three different concerns share one tangle. In VantyGo, vendor onboarding, per-vendor catalogues and order routing are separate things.

Onboarding answers who a vendor is and whether they are ready to trade. A catalogue answers what that vendor sells, and each vendor has its own, with its own storefront branding. Routing answers where an order goes once it exists, and which vendor and which delivery or booking flow handles it. Because these are separate, you can change one without breaking the others. A new vendor type with a different catalogue shape does not require touching how orders are routed, and a change to routing does not risk a vendor's menu.

Booking for service vendors fits the same shape: it is another route for an order-like request, not a special case bolted into the catalogue.

Hebrew, Arabic and English from the start

The interface runs in Hebrew, Arabic and English, with right-to-left layout for Hebrew and Arabic. We treat that as an architecture concern, not a translation task. Layout, spacing, icons that imply direction, forms and maps all need to behave correctly when the page flips. If you build for left-to-right and retrofit, you will find the problems one screen at a time, in production. We covered the reasoning in more depth in our post on multilingual and right-to-left engineering.

What this means for your platform build

If you are scoping a marketplace, ordering or booking platform for a client, the lessons transfer directly: choose one front-end codebase if your surfaces share a design language, put slow or failure-prone work behind queues, announce changes as events, and keep onboarding, catalogues and routing apart. Decide on languages and directionality on day one.

We are also candid about limits. Card payments in VantyGo are in a sandbox and are not live, and we scope payments, native store releases and compliance as explicit line items in a written quote instead of folding them into an optimistic estimate. On ownership, our usual terms apply: you can buy out your product source code, while VantyRex backend logic and infrastructure stay ours.

If you want to look at the pricing structure, start at /pricing. If you have a platform in mind and want to test the architecture against it, get in touch at /contact and we will start with a 15-minute scoping call.