One source of truth for the numbers your team argues about. Built on your Postgres with Streamlit, deployed in your environment, ready in 2 to 4 weeks. No enterprise BI invoice. Fixed price quoted before any code gets written.
PROBLEMS I HEAR EVERY WEEK
You don't have a reporting problem. You have a plumbing problem. The fix is an ETL layer that pulls from each source into a clean reporting schema on Postgres, refreshed on a schedule. After that, every report runs off the same numbers. I built this exact stack at Wavess.io with 520+ data points flowing in from Trustpilot, news scrapers, and hiring sources.
That deck builds itself. A dashboard your team bookmarks shows the same numbers, refreshed without anyone touching a spreadsheet. The Monday standup happens in front of the dashboard instead of around a deck someone built at midnight. The Wavess sales team replaced a 3-hour per prospect research drill with a Streamlit page they checked before every pitch.
Three different tools, three different definitions of MRR, three different cuts. The fix is not another tool. It's one query that everyone in the room agrees on, sitting in a reporting schema your engineers can read and change. Week 1 of the engagement is a scoping doc where we write down the definition of every metric on paper before any code gets written.
The founder shouldn't be the analyst. A dashboard with the right filters and drill-downs answers 80% of board questions without a SQL query. The other 20% live as saved queries your team can run themselves. After the handoff, the 11pm SQL session goes away.
Tableau and Power BI are great tools. They're also priced and scoped for companies twice your size. A Streamlit dashboard on your existing Postgres costs $240 a year on a $20-a-month VPS. Same numbers, same drill-downs, a fraction of the bill. The engagement runs in weeks, not quarters.
A dashboard nobody opens is a failed project. The failure usually starts in week 1, when nobody wrote down the decision the dashboard was supposed to support. Every engagement I run starts with a one-page scoping doc that names the decisions, the metrics, and the team that uses it. If the doc doesn't survive scrutiny, the dashboard won't either.
How I solve it
Each move maps back to one of the quotes above. None of them is optional.
The "dashboard nobody opens" failure starts with a fuzzy purpose. Week 1 produces a one-page scoping doc that names every decision the dashboard supports, every metric that informs those decisions, and the definition of each metric in plain SQL. Both of us sign off before I build a thing. A dashboard rarely gets abandoned if the team agreed up front on what it was meant to answer.
The "scattered tools" problem is an ETL problem first and a dashboard problem second. Most failed dashboards sit on top of un-cleaned data. I pull from Stripe, your CRM, your product database, and any other source into a reporting schema on your Postgres. SQL transforms get versioned. By the end of week 2, you can run a query against the new schema and get the same number you'd calculate by hand.
The "MRR debate" problem ends when there is one query that returns MRR and everyone in the room agrees with it. I commit the metric definitions to a versioned file in your repo. When sales asks for a different cut, that's a new metric, not a redefinition of the old one. The dashboard reads from the same definitions your engineers can review.
A Streamlit dashboard on your existing Postgres costs less than $300 a year. Power BI plus Snowflake plus Fivetran costs $5,000 to $15,000 a year before any work happens. For a seed-stage team that doesn't already own those licenses, the lean stack wins on cost, on time-to-deploy, and on what your engineers can maintain. If you already have Power BI or Snowflake, I build there instead.
Python and SQL are languages your team already speaks. The dashboard ships to your repo with a README that covers local setup, deployment, ETL schedules, and the metric definitions. When sales asks for a new cut next quarter, your engineer adds it without booking a Tableau consultant. After week four, your team owns the system.
The operational lifecycle, after handoff. ETL pulls from your data sources into a reporting schema on Postgres. Versioned SQL transforms produce the metric tables. Streamlit reads from the metric tables. Refresh runs on a schedule your team controls. Your engineers extend or modify any layer using languages they already know.
The Setup: A fintech SaaS startup's sales team was burning 3 to 4 hours per prospect stitching Trustpilot reviews, hiring data, and recent news together by hand. Some pitches got prepped poorly. Some got skipped. The team knew the data existed but couldn't get to it fast enough to use it.
What got built: An ETL pipeline that pulled 520+ data points (154 hiring records, 366 customer reviews) from Trustpilot API and industry news scrapers. Multilingual text normalization handled German and English reviews in the same pipeline. A Streamlit dashboard with filters by competitor, market segment, and time period sat on top. Reps could pull a competitor's full picture in under a minute.
What changed: Per-prospect research time dropped 70%, from 3 hours to under 1. Reps walked into pitches with named competitor weaknesses to position against. The team ran more pitches per week with better prep on each one.
Stack: Python, n8n, BeautifulSoup, Trustpilot API, Streamlit, PostgreSQL
Work done as Data Science Intern at Wavess.io between July and October 2025.
Get a similar resultDELIVERABLES
A one-page scoping doc that names the decisions the dashboard supports, the metrics behind them, and the SQL definition of each metric
A source-system audit that maps where your data lives and what's broken about it (sometimes worth the engagement on its own)
Clean ETL pipelines that pull from your sources into a reporting schema on your Postgres, documented and scheduled
A versioned set of SQL transforms that produce the metric tables your dashboard reads from
The dashboard itself (Streamlit or Metabase), deployed to a URL your team can bookmark
A handoff README covering local setup, deployment, ETL schedules, and known limitations
A 30-day post-launch question window for fixes and small additions
How It Works
A 30-minute call. We go through your data sources, the decisions the dashboard needs to support, and the metrics behind them. I tell you straight whether a dashboard is the right answer for your case. No deck. No pitch.
I write the one-page scoping doc covering decisions, metrics, SQL definitions, the stack, and your fixed price. A source-system audit maps where every metric's data lives and what's broken about it. If at the end of the week it isn't the right fit, you keep the documents and we part ways. No contract trap.
ETL scripts pull from your sources into a reporting schema. SQL transforms get versioned in your repo. By end of week, you can run a query against the new schema and get a number that matches what you'd calculate by hand.
The Streamlit or Metabase build. KPI tiles, filters, comparison views, drill-downs. End of week is a draft you can poke at with real data.
Stakeholder feedback session, one round of changes, deployment goes live, walkthrough call. The README ships with the repo. The 30-day post-launch question window starts here.
What slows the build down. Data sources without APIs that need scraping or manual export. Metric definitions your team has not aligned on internally. A messy data layer that needs heavier cleanup before any dashboard can sit on it. I flag these in week 1 if I see them coming, and the timeline expands to 4 to 6 weeks if it happens.
If you're not sure which side you fall on, book the call. I'll tell you straight.
2 to 4 weeks for most builds. 4 to 6 weeks if your data needs heavier cleanup before the dashboard layer can sit on it. I scope this in week 1 and tell you up front if the longer track is more likely.
Both. Most dashboard projects fail because the dashboard is built on top of un-cleaned data. I build the ETL first, then the dashboard. One engagement covers both layers.
That's the most common starting point. Week 1 maps where everything lives and what's broken about it. The output is a one-page architecture doc with trade-offs and a recommended path. We agree on that path before any ETL gets written.
Cost and ownership. Power BI Pro is $14 per user per month. Tableau Creator is $75. Snowflake's smallest production warehouse runs $200 to $500 a month. Add Fivetran and you're at $5,000 to $15,000 a year before any actual work. A Streamlit dashboard on Postgres runs $240 a year on a $20 VPS. After I leave, your engineers can extend it because Python and SQL are languages they already speak.
Yes. The Streamlit and Postgres default is for clients who don't already own a BI stack. If you do, I connect to your warehouse or build inside your existing tool. Same outcome, different backend.
Yes. The dashboard is Python on Postgres. Both are languages your engineers already use. The handoff README covers local setup, deployment, ETL schedules, and the metric definitions. Most teams ship their first new feature inside a month.
Real-time (sub-second) dashboards are rarely worth their cost at seed stage. Most dashboards I build refresh every 15 minutes to 1 hour, which is enough for almost every business question. If you have a real-time use case (fraud monitoring, live ops), I can wire up websockets or polling.
By usage and decisions, not by chart count. The scoping doc names what the dashboard is meant to inform. We measure against that at the 30-day review: are the right people opening it, are meetings running off the same numbers, has the founder stopped writing SQL at 11pm.
A 20-minute scoping call. We go through your data sources, the decisions you want the dashboard to support, and whether the project is a fit. A one-page proposal lands in your inbox within 48 hours of the call.