What a marketplace aggregator costs for Wildberries and Ozon

In short. An MVP of an aggregator with stock synchronisation and basic analytics takes 6–10 weeks. A full dashboard with automatic repricing, unit economics and BI takes 3–4 months and costs roughly twice as much. What moves the estimate is not the number of marketplaces but their API limits and the state of the seller’s accounting system.

We quote in roubles, so the figures below are given as proportions and timelines rather than converted amounts — convert at the rate of the day if you need an absolute number, or ask us for a quote.

What the budget is made of

Line	Share of budget	What is inside
Exchange with the marketplaces	30–40%	API clients, queues, retries, handling limits and errors
Stock and price synchronisation	15–20%	Allocation rules, reserves, marketplace priorities
Link to the accounting system	15–25%	Matching the product catalogue, order exchange, returns
Analytics and reports	10–20%	Profit per SKU, funnel, advertising, exports
Launch and stabilisation	10–15%	Data reconciliation, resolving the first weeks’ discrepancies

The first line is almost always underestimated. Connecting the Wildberries or Ozon API genuinely is not hard. What is hard is making the exchange survive rate limits, temporary failures and changes in the APIs themselves without losing orders or double-counting stock. The typical mistakes are covered in marketplace API limits and errors.

Three scenarios

Synchronisation, 6–10 weeks. One source of stock, two marketplaces, price upload, order intake. The point is to stop maintaining stock by hand and to stop selling what is not in the warehouse.

Dashboard with analytics, 3–4 months. This adds profit per SKU including commissions and logistics, alerts, handling returns, and repricing rules. This is where an aggregator starts making money rather than only saving time.

Dashboard with automatic rules and BI. Automatic repricing against a target margin, supply forecasting, advertising analytics, several legal entities and warehouses. The complexity grows with the number of rules, not the number of marketplaces.

What moves the estimate most

API limits and how they behave. Each marketplace has its own request-rate restrictions and its own failure modes. A system that simply fires requests works on ten products and breaks on ten thousand. The right architecture, a queue with priorities and retries, is built in from the start, because rewriting it later costs more than doing it.

The state of the accounting system. If the catalogue in the accounting system and the listings on the marketplaces have never been matched, matching them is the first stage, and it is sometimes more expensive than the exchange itself. See what an accounting integration costs; in an aggregator that exchange is usually two-way.

The number of warehouses and legal entities. One warehouse and one entity is a simple task. Three warehouses, fulfilment by the marketplace and by the seller at the same time, two entities with different commission terms: that is different stock allocation logic, and it gets written from scratch.

What inflates a project quietly

Returns and cancellations. They get remembered last, and they change stock, profit per SKU and the reconciliation with the accounting system. A return scenario planned in advance saves weeks.

Treating stock discrepancies as normal. Sellers get used to stock figures that “do not quite add up”. In a system that means a separate reconciliation mechanism and a discrepancy log, otherwise there is no way to work out the cause a month later.

Advertising as a separate world. Analytics for marketplace ad campaigns means separate APIs, separate data delays and its own attribution logic. If it is needed, it belongs on its own line of the estimate rather than as a bullet in a list of reports.

What brings the cost down

Start with one marketplace. The second one connects to an existing architecture noticeably cheaper than the first, because the queue, the retries and the log already exist.

Stock first, analytics second. Synchronisation pays off immediately and measurably: sales of out-of-stock items stop, and so do the penalties for cancellations. Analytics on unreliable data is pointless, so it comes second.

Do not build your own warehouse for data straight away. An ordinary database is enough at the start. A separate analytical store is needed when the volume demands it, and that shows up in report response times rather than in expectations.

What ownership costs

The benchmark is 15–20% of the development cost per year, with one particular feature: the marketplaces change their APIs regularly, and that is not a hypothetical risk. Support for this kind of product always includes time for adapting to changes, otherwise the exchange will stop during a peak season.

Common questions

Why not use an off-the-shelf service? For ordinary trading an off-the-shelf service is cheaper and faster, and it is where to start. Custom development is justified when you need your own stock allocation logic, a non-standard link to the accounting system, or data the ready service does not provide.

How soon is the first effect? 6–10 weeks to working synchronisation. The effect is easy to count: how many cancellations and penalties there were before and after.

Can it be done on a small budget? If the task is uploading prices to one marketplace on a schedule, yes. Full two-way synchronisation with an accounting system cannot be done for that.

What counts as a successful MVP? Not “the exchange works” but “the weekly stock reconciliation balanced”. The first is checked by feel, the second by numbers.

The order that costs least

Inside the range, the price is set by the API limits, the state of the catalogue in the accounting system, and the number of warehouses and legal entities.

The sensible order is stock, then money, then automation. It is also the cheapest order, because every next step is built on data that has already been verified.

How we do it: marketplace aggregator development.