SellerX Reviews 5x More Data With the Same Six People
Analytics beyond the data team: SellerX built its own e-commerce analytics platform, letting six non-technical employees review 5x more data and compress a month of work into under a week.
5x
More marketplace data reviewed by the business team
1 month
Of work now completed in under a week
100 GB
Of marketplace data processed daily by the platform the team owns
- Founded
- Berlin, 2020
- Investors
- L Catterton, Sofina, BlackRock and more
- Website
- sellerx.com
A team of 6 non-technical employees use the app to make decisions based on Amazon information. It is allowing this team to be significantly more efficient and structured in the way they work and they are very happy with the improvements in speed. This team is now able to review 5x more Amazon data than their previous approach.

In most companies, the people who make decisions wait on the people who prepare data. Requests queue behind other requests, a specialist translates the question into a spreadsheet, and a month can pass between asking and knowing. This is the story of a company that ended the wait.
Meet SellerX, a Berlin-based e-commerce group that acquires Amazon's most successful sellers and scales their brands. It is one of the largest e-commerce aggregators in Europe, managing more than 50 brands, and its acquisition decisions run on data: products, reviews, and prices across hundreds of thousands of listings on four continents.
The result first
Six non-technical employees at SellerX now review five times more marketplace data than before, on a platform that processes around half a million data points and 100 GB of information every day. Work that took the team a month is finished in under a week, and the decisions the business runs on, which brands to look at, which products to track, arrive that much sooner.
None of that came from buying an analytics product or growing the analyst team. It came from software SellerX built and owns.
What the work looked like before
The information behind an acquisition decision lived in many places: Amazon listings, company websites, internal databases. Assembling it meant visiting each source, copying what mattered, and pasting it into Excel, listing by listing, for teams handling hundreds of thousands of products.
Mike Woodcock, Head of AI & Automation at SellerX, was tasked with fixing the pipeline. His requirements were business requirements: a web interface any colleague could open, company sign-on, and the ability to change the tool quickly as the teams gave feedback. The collection work would run in the background; the decision-makers would open the app and find everything ready.
What changed, side by side:
| Before | With the platform SellerX built | |
|---|---|---|
| Gathering the data | Manual copying from marketplaces into Excel | Collected automatically in the background |
| Who can use it | Whoever built the spreadsheet | Six non-technical employees, with company sign-on |
| Volume reviewed | Limited by analyst hours | 5x more data, 100 GB processed daily |
| A month of analysis | A month | Under a week |
| Changing the tool | A request to engineering | A quick call, a new version the next day |
We are moving significantly faster, which has been very very useful. To have a quick call with the end user of the app and then the next day you have a nice basic interface for them to use, to double check if they like the setup, and see if it's going to work, it's just fantastic.

The two paths that did not work
The team's first attempt was Streamlit, the common starting point for Python data tools. It was good enough for a demo and no further: the tool ran out of memory and grew less reliable the longer it ran, and the team was facing the familiar ending, build a prototype, then pay to build the real thing a second time.
The conventional alternative, a React frontend with a separate Python backend, solved the ceiling but at the cost of speed.
With Reflex it is ten times faster than developing with React and FastApi.

Reflex removed the choice between the two: the first version was already the finished product, delivered at first-draft speed, with nothing built twice and nothing thrown away. For how to run this decision on your own tools, see our build vs. buy framework for internal software.
How it was built
This section is written for your technical team. In short: background jobs collect the data, and the business team works in a governed interface on top.
View the technical details
The platform ingests roughly half a million data points and 100 GB of marketplace data daily, combining web scrapers and API integrations. Long-running collection tasks run as Reflex background events; results are displayed in AG Grid tables carrying images, links, and text data at volume. Company sign-on uses Azure Auth, one of Reflex's supported authentication options.
The team's first version was built in Streamlit, which re-runs the entire script on each user interaction.
Streamlit's linear execution model, which re-runs the entire script upon each user interaction, can lead to inefficiencies and potential memory leaks, posing challenges for long-term projects.

For teams weighing the same move, our Streamlit migration guide covers it in full. Compared with the earlier Streamlit codebase, the application is event driven and organized for long-term maintenance.
With Reflex the code is much more organized and every time the user does something it's more dynamic, more event based.

Also for deploying everything is significantly easier. It's all just Python. You just open the right ports, add SSO, and then everyone that needs to have access can use the app.

The multiplier
The platform did not speed up a back office. It removed the wait entirely: the six people who own the decisions gather, review, and act on the data themselves, at five times the previous volume, without SellerX hiring anyone to make it possible. That is why a month of work now fits in a week.
For the same pattern at a lean venture firm, see how Ansa built the deal-sourcing platform it could not buy.
Frequently asked questions about ecommerce analytics platforms
Can non-technical teams use custom analytics tools?
Yes, when the tool is built for them. At SellerX, six non-technical employees use a custom analytics platform daily to make acquisition decisions from Amazon marketplace data. The data collection runs automatically in the background; the team opens the app and finds everything ready, and now reviews 5x more data than before.
Why do teams move off Streamlit for production analytics?
Streamlit re-runs the entire script on each user interaction, which SellerX found led to inefficiencies and potential memory leaks on long-term projects, alongside limited layout control. The common pattern is prototyping in Streamlit and then rebuilding the real application afterwards. SellerX moved to Reflex so the first version was the production version.
How much faster is building an internal platform in Python than with React and a separate backend?
In SellerX's experience, ten times faster than developing with React and FastAPI, with iteration measured in days: a quick call with the end user, and a working interface to review the next day.
What scale can a custom-built analytics platform handle?
SellerX's platform processes around half a million data points and 100 GB of marketplace data daily, covering hundreds of thousands of products across four continents, with long-running collection jobs in the background and high-volume data tables in the interface.
See what other teams built
See what your team could build.
Tell us about your workflow. See how Reflex can help you turn it into an application.