Demo case study. This project is fictional and exists to test the content workflow. Replace or remove it before launch.
The starting point
Nordwind operates wind farms and sells the generated energy to municipal utilities and commercial customers. Operations ran on Excel: production data from three sites, maintenance schedules, feed-in forecasts and customer contracts in separate files. Every Monday, the team spent hours assembling metrics before anyone could make a decision.
Leadership asked for a “dashboard”. In the first conversation it became clear that the real problem was not visualisation but the lack of a shared data foundation. A dashboard built on late or inconsistent data would only move the effort elsewhere.
My role
I was the lead product engineer responsible for discovery, the data model, implementation and the pilot. A designer shaped the interface; a colleague from operations contributed the domain rules. The team was deliberately small: three people, short paths, weekly decisions.
Approach
1. Understand the decision, not the spreadsheets.
Instead of collecting requirements, I joined the weekly operations meetings for two weeks. The key question was: which number leads to which action? That produced four core views: site status, feed-in, maintenance and contract volume. Everything else was deliberately left out.
2. A domain model before an interface.
We translated the language of operations into a PostgreSQL schema: site, measurement point, time window, contract, maintenance window. Data arrives through a nightly CSV import and a narrow API. The import pipeline is idempotent, logs failures and can process the same day more than once. It sounds unglamorous, but it was the precondition for numbers people could trust.
3. A thin, traceable application.
The frontend is a Next.js application with server components for the overview pages and a few client islands for filters and charts. Database access goes through Drizzle; every query is typed and traceable. The important metrics are calculated on the server so that everyone sees the same number. For the pilot, a single Cloudflare deployment with a managed Postgres instance was enough.
4. Pilot, not big bang.
After four weeks, a first version went to two people in operations. A week later, a third pilot customer joined. Feedback went straight into the weekly rhythm. The bravest decision was not to build the Excel export at first — even though it was at the top of the wish list. Once the pilot showed that people trusted the dashboard, the export became unnecessary.
Outcome
- The pilot went live after six weeks, not after the originally planned quarter.
- Manual reporting dropped by around 40%.
- Three pilot customers used the application daily; two extended after the pilot.
- The most important metric — time from data delivery to decision — fell from a day to under an hour.
What I took away
A dashboard is not a product. A product is the decision someone can make afterwards. The hardest technical work was not the frontend but cleaning the data and defining the terms. If you build a dashboard, you build a data model and a process first — and an interface second.