Case Study
Turning Scattered Market Data Into Finished Reports
Client
A Polish car dealership (NDA)
Industry
Automotive / dealer networks
Services
Market monitoring, data platform, BI reporting, cloud monitoring
Tech stack
Python · PostgreSQL · Power BI · Azure
Challenge
The market picture the client works with is scattered across several independent portals. Each describes what it lists in its own way and updates on its own rhythm.
Solution
An automated monitoring system - running unattended on the client's own server - keeps that picture current, a PostgreSQL warehouse holds it as one consistent, day-by-day record, and Power BI turns it into up-to-date, decision-ready dashboards, with the system reporting its own status to cloud monitoring.
Outcome
Analysis that had to be rebuilt each time it was needed is now a daily automated refresh of the whole picture - assembly absorbed by the system, and the ad hoc summaries replaced by an unbroken, reliable view of the market and its history.
The Challenge
The client competes in a market whose facts are published in fragments, across several independent portals. No portal coordinates naming or update timing with the others - the fragments never added up to one view.
That is a property of the market itself, not of any one company, and it is far from unique to automotive retail. In many industries the information a business needs to make good decisions sits in tools, partners, or systems that were never designed to talk to each other. The usual fallback is the same almost everywhere: someone puts the picture together by hand. The cost is delay - by the time the picture is assembled, the market has already moved.
Any such comparison is accurate on the day it is made and leaves nothing behind to measure the next week against. The market keeps moving.
They needed those disconnected sources gathered into one readable whole: kept current, showing today against yesterday, and making no standing claim on anyone's time.
Our Approach
A picture that keeps itself current
The market moves daily, so the picture has to be re-made daily. The system does that to a schedule and without anyone's involvement: because the sources are structured differently and move on different rhythms, it reconciles what differs between them - naming, units, categories, timing - and holds each day's picture to a single shape, complete and checked, before anything downstream sees it.
The entire pipeline runs on-premises, on the client's own server - scheduled, unattended, and self-reporting. The market data stays in the client's own warehouse and reaches the Power BI dashboards in the client's own Microsoft 365 tenant through the on-premises gateway; the only thing that reaches our cloud is status telemetry for monitoring.
Three engineering priorities shaped the build:
- Resilience - the system validates its own results before anything is written. If the day's picture fails its checks, the warehouse is left untouched and the team is told, so an unverified number never reaches a dashboard.
- Observability - the system reports the state of each daily refresh to an Azure monitoring channel, where the team sees it as it happens; that history is retained in the cloud.
- Reach and history - the history grows every day, so trends become visible and the picture of the market more complete; it also covers brands the client does not sell today, which gives a sound basis for deciding where to expand next.
A single source of truth
Information from each source is normalized and loaded into a PostgreSQL warehouse, where inconsistent formats, naming, and structures are reconciled into one consistent whole, with each day kept as its own layer rather than overwriting the last. That daily snapshot design means the warehouse doesn't just show the market as it is; it accumulates the market's history, so trends - prices moving, offers shifting - become visible in a way no single snapshot could ever capture.
Reporting people actually use
On top of that structured data, we built Power BI dashboards around how the client's team actually makes decisions - surfacing the numbers that matter. Because the system behind them refreshes automatically, the reports show the market as it stands today, not as it stood when someone last assembled the file by hand.
Data flow
Market sources
independent portals
Market monitoring
on the client's own server
reporting its own status to
Azure monitoring
PostgreSQL data warehouse
Power BI dashboards
The Outcome
What the market forced to be redone every time it moved now runs as a monitored background process. The client's team gained:
- Continuous visibility - the whole market in one view, refreshed automatically every day, in place of periodic snapshots put together by hand.
- The day's picture is ready before the day starts - the current view is waiting for the team when it sits down.
- Problems that surface on their own - the system reports its own status to cloud monitoring, and that telemetry feeds our service operations directly, so an issue reaches the people who fix it and is resolved under the support agreement.
- A growing market history - day-by-day records that turn dashboards from a current snapshot into trend analysis.
- Analyst time goes further - assembly is the system's job, so the team starts from what the numbers mean.
Capabilities behind this project
Recognize this pattern in your own business?
Tell us about your case