Case Study 2: Building an Internal Dashboard Culture at a Growing Company

This case study is a composite — drawn from public blog posts by Uber, Netflix, Stitch Fix, and others, plus direct experience with several growing companies that adopted Streamlit between 2020 and 2023. The specific company is fictional but the patterns are real. The purpose is to show how Streamlit adoption plays out in practice, what problems it solves, and what new problems it creates.

The Situation: A Company Drowning in Ad Hoc Requests

The fictional company — let's call it Wayfinder — is a mid-sized tech company with about 500 employees and a 30-person data science team. In early 2020, Wayfinder's data team faced a common problem: too many ad hoc data requests.

Product managers wanted to see weekly user-retention numbers. Marketing wanted custom cohort analyses for each campaign. Engineering wanted performance dashboards for the main service. Customer support wanted a tool for looking up specific users. The CFO wanted revenue forecasts with different scenario parameters. Each of these was a legitimate request, but the data team was spending most of its time answering them one at a time, rebuilding similar SQL queries and similar matplotlib charts.

The team tried several approaches before Streamlit. They experimented with Jupyter notebooks ("just send a notebook") — this worked for technical audiences but failed for product managers who didn't want to run code. They tried Tableau for some dashboards — it worked but required license fees for every user and didn't integrate well with their Python-based analytics pipeline. They built a few Flask apps — these worked for specific use cases but took weeks to build and were hard to maintain.

In mid-2020, a junior data scientist proposed trying Streamlit for a specific project: a user lookup tool for customer support. The tool needed to take a user ID, pull the user's data from the warehouse, and display a few charts showing their activity over time. Standard request, usually a two-week Flask project.

The junior data scientist built it in one afternoon with Streamlit. The customer support team loved it. Within a week, the tool was in daily use by 20 people.

The Explosion

Word spread through Wayfinder quickly. The head of customer support told the head of marketing about the new tool. Marketing asked: "Can we have one like that?" The junior data scientist built a cohort analysis dashboard in two days. Marketing loved it.

Then sales asked for a pipeline dashboard. Then the product team asked for a feature-adoption dashboard. Then finance asked for a revenue-forecasting tool. Within three months, the data team had built fifteen Streamlit dashboards for fifteen different internal customers.

The efficiency gain was dramatic. A dashboard that would have taken two weeks as a Flask app took two days as a Streamlit app. The data team's backlog of ad hoc requests dropped from six months to three weeks. The team shifted from answering one-off questions to building tools that answered recurring questions automatically. The internal customers got more and better tools; the data team had more time for actual data science work.

By the end of 2020, Wayfinder had about 50 Streamlit dashboards in production, serving every major department. The data team estimated that Streamlit had saved them approximately 2,000 hours of work in the first year — roughly the equivalent of two full-time engineers.

The First Challenges

But the explosion also created problems. The first challenge was infrastructure. Fifty Streamlit apps running on a shared server eventually ran out of memory. Each app held its data in memory (because of @st.cache_data), and with fifty apps × several gigabytes each, the server started to swap. The team had to migrate to multiple servers, then to a Kubernetes deployment with autoscaling.

The second challenge was authentication. Streamlit Community Cloud is fine for public apps, but Wayfinder's dashboards contained confidential business data. They needed authentication with the company's SSO provider. Streamlit didn't support this out of the box. The team built a custom auth layer using a reverse proxy (nginx with OAuth2 proxy) in front of Streamlit, which worked but added operational overhead.

The third challenge was code quality. The early Streamlit dashboards were written quickly, with copy-pasted data-loading code, hardcoded paths, and no tests. When the warehouse schema changed, half the dashboards broke simultaneously. The team instituted coding standards: shared data-loading modules, version-pinned dependencies, a template for new apps, and basic smoke tests before deployment.

The fourth challenge was discoverability. With fifty dashboards, internal users had trouble finding the right one. The team built an index dashboard — itself a Streamlit app — that listed all the others with descriptions and search. They also added a Slack bot that let users query "show me the dashboard about X."

The fifth challenge was maintenance. Streamlit apps written quickly accumulated technical debt. When the original author left the team, new team members had to learn each app from scratch. The team instituted a "dashboard retirement" process: every quarter, review the dashboards, deprecate the unused ones, and refactor the important ones.

The Unexpected Successes

Alongside the challenges came some unexpected successes.

Non-data-team contributors. Engineers from other teams started building their own Streamlit dashboards for their own needs. An SRE built a service-health dashboard. A frontend engineer built a design-system audit tool. A finance analyst built a budget tracking tool. The data team did not build these; they just provided the infrastructure and best practices. Streamlit became a shared tool across the company.

Faster experimentation. Product managers started building their own "prototype dashboards" to explore ideas before requesting official features. A PM would build a quick Streamlit app with mock data, use it in user-research sessions to validate the concept, and only then file a feature request with engineering. This shortened the product development cycle significantly.

ML model demos. The ML team used Streamlit for model demos. A new recommendation model would be deployed as a Streamlit app first, so product managers and designers could play with it and provide feedback before full integration. This caught several issues early (e.g., models that produced weird outputs for edge cases) that would have been expensive to fix later.

Training and onboarding. New data scientists used Streamlit as their first "get to production" project. Write a dashboard, deploy it, get feedback from internal users — a complete data science workflow that touched every part of the stack. Streamlit made this possible in days instead of weeks.

Internal build days. The company's quarterly internal build days produced more usable output after Streamlit adoption. Teams could build working prototypes in a day, deploy them, and have real users try them by the evening demo session. Many of the build-day projects evolved into real products.

The Governance Model

As Streamlit adoption grew, Wayfinder needed a governance model. Who owns the dashboards? Who approves deployments? Who handles incidents when a dashboard breaks?

They converged on a three-tier model:

Tier 1: Sandbox. Any employee could deploy a Streamlit app to a sandbox environment. No review, no approval. These apps were not production-quality and were explicitly marked as experimental. Most build-day projects started here.

Tier 2: Team tools. A team could promote a sandbox app to a team tool by adding proper documentation, basic testing, and an owner. The data engineering team reviewed team tools for security and infrastructure concerns.

Tier 3: Company-wide. Company-wide dashboards (the ones that every department used, like the revenue forecasting tool) required full review: code review, tests, monitoring, on-call rotation, and a documented owner responsible for uptime. These looked more like traditional software projects than like notebooks.

The tier system let Streamlit be both a quick-prototyping tool (Tier 1) and a production infrastructure (Tier 3) without forcing everything through the same process. The lightweight path for quick tools preserved the speed advantage; the heavyweight path for important tools provided the reliability.

Theory Connection: Tools Enable Culture Change

The Wayfinder story illustrates a broader pattern: new tools can enable cultural changes that were previously blocked by friction. Before Streamlit, the data team at Wayfinder was stuck answering ad hoc requests because building dashboards was expensive. After Streamlit, dashboards became cheap, and the culture shifted toward "build a tool" instead of "answer the question once."

The same pattern appeared with the non-data-team contributors. Before Streamlit, only people with web development skills could build internal tools. After Streamlit, anyone who could write Python could build a dashboard. This enabled a broader set of employees to contribute tools, which shifted the company's culture toward tool-building across disciplines.

The pattern is a specific case of Conway's Law in reverse. Conway's Law says that the structure of a company's software mirrors the structure of the company's communication. The reverse pattern — which someone should name — is that new software tools enable new communication patterns. Streamlit enabled the data team to ship tools that internal customers could use directly, which changed who talked to whom and about what.

For practitioners, the lesson is that tool choice is not just a technical decision — it is a cultural one. The tool you pick shapes how your team works, who can contribute, and what kinds of problems become tractable. Streamlit's low-friction approach enables certain kinds of work that high-friction alternatives do not. When you adopt Streamlit (or any similar tool), be prepared for the cultural implications, both the opportunities (faster iteration, broader contribution) and the challenges (governance, maintenance, infrastructure).

Discussion Questions

1. On the tiered governance model. Wayfinder used three tiers: sandbox, team, company-wide. Is this the right structure for a growing company, or is there a better alternative?

2. On the maintenance challenge. Streamlit made building dashboards easy, which led to many dashboards, which created maintenance debt. Is this a problem with Streamlit or with the company's discipline?

3. On non-data-team contributors. Streamlit let non-data-team employees build their own dashboards. Is this broadly good (empowerment) or problematic (shadow IT)?

4. On tool-enabled culture change. The case argues that new tools enable new cultures. What other tools have had similar effects in your experience or in the companies you know?

5. On authentication and security. Wayfinder built a custom auth layer because Streamlit didn't provide one. Should Streamlit add built-in authentication, or is the current approach (roll your own) appropriate?

6. On your own organization. If you introduced Streamlit in your workplace, what governance model would you propose? Which challenges do you anticipate?

The Wayfinder story is a composite, but the patterns are real. Companies that adopt Streamlit see similar dynamics: an initial explosion of dashboards, followed by infrastructure and governance challenges, followed by a more mature tooling culture. The tool is a lever; what it lifts depends on the people and processes around it. When you introduce Streamlit (or any similar tool) in your own work, think not just about the technical capabilities but about the cultural patterns it enables.