Rethinking How We Share Insights: Webapps vs Dashboards
Dashboards are easy to start with, but hard to grow with.
The whole lifecycle of an analytics or data science product can be managed using just three types of tools: one for ETL, one for Analysis/Modelling, and one for Sharing.
With the help of modern distributed computing platforms like Databricks and Snowflake, the ETL part has become relatively easy. These platforms now offer great Python and R wrappers, making querying and data wrangling straightforward. You can create your .py or .r files, process the data directly on these platforms - and the best part is, they’re language-agnostic.
Then comes the Analysis and Modelling stage. You have Python, R, or even Julia. This part is fairly sorted by now.
But here’s the real question: how do you share your work?
Traditionally, for BI teams, dashboards have been the go-to method. You receive a requirement from the stakeholder → do your analysis and generate the outputs → build a dashboard with the KPIs and metrics.
That’s the classic way of doing things - especially in the BI domain.
Tools like Power BI and Tableau have served this purpose well. They’re quick, intuitive for simple plots, and can be easily deployed if your organisation already has a server setup. For one-off metrics or light dashboards, they work quite effectively.
But they come with limitations.
When it comes to webapps, the typical tools used by DS teams are R Shiny or Streamlit (for Python). These require more coding effort, unlike the low-code/no-code experience of traditional BI dashboards. That said, I’ve grown to appreciate webapps more - especially in this GenAI era, where writing code is no longer a bottleneck.
Recently, at my current organisation, we had to develop a product. We initially went with Tableau since that was the organisational preference. The dashboard had 13 different plots and several analytical computations built in. But soon, we were struggling to scale it. Even minor requests would take longer than I thought they should.
Eventually, we moved the whole thing to Streamlit.
The difference was striking.
The dashboard was heavy - it would take time to load in Tableau. That problem just disappeared with Streamlit.
Scaling became easier. The entire structure became modular. Adding a new plot was as simple as writing a new function. We didn’t have to worry about the underlying data model like we did with Tableau.
And the possibilities? They felt limitless.
When you build something with a programming language, you unlock a broader horizon. You can tap into the entire Python ecosystem. Need an advanced statistical test? A new type of chart? A GenAI integration? It’s just a library away.
There’s also the API route - another powerful way to share your work, especially with tech teams or platforms where your model needs to go into production. But APIs aren’t ideal when sharing directly with stakeholders. They lack the visual interface or interactivity that decision-makers usually prefer.
All this has made me a strong believer in using webapps over dashboards. Sharing data insights shouldn’t be a bottleneck.
In the end, the best tool is the one that lets you move fast without breaking clarity. For me, that’s increasingly looking like webapps.
But I’m also curious - what do you think are the downsides of webapps?
If you've faced similar trade-offs, or have a different take, I’d love to hear from you.