Beyond BI: How a Healthcare Scaleup Built a Data App Platform That Cut Costs 70% and Shipped 5x More Applications

Scoping the Platform

The engagement started with scoping sessions across the data team, engineering, and security to understand what the client actually needed — and what had already been tried.

Key Findings

• Business units had strong demand for interactive data tools, but the data team was stuck shipping dashboards at ~1 per week
• The existing Kubernetes infrastructure was underutilized and could host the new platform without additional infrastructure spend
• HIPAA/HITECH compliance was non-negotiable — any solution needed OAuth2, role-based access, and dynamic data masking for PII/PHI
• Previous internal attempts to deploy data apps had failed due to gaps in traditional application engineering skills

Platform Decision

Streamlit was chosen for its Python-native approach — the data team already knew Python, so adoption friction would be minimal. The real engineering challenge was the security and deployment layer, not the application framework itself.

Platform & Components

Two parallel workstreams launched: the core Streamlit-on-Kubernetes platform and the React component library that would extend it.

Streamlit on Kubernetes

The platform was deployed on the client's existing Kubernetes clusters with a multi-level security architecture:

• OAuth2 authentication connected to the federated identity provider
• IdP group-based access control for application-level permissions
• Dynamic data masking tied to warehouse roles for HIPAA/HITECH compliance

Why this approach: The client's Kubernetes infrastructure was already provisioned and maintained. Building on it meant zero new infrastructure cost and familiar operational patterns for the engineering team.

React Component Library

A custom repository for Streamlit React components, packaged as stable pip packages. This gave the data team UI capabilities beyond Streamlit's native components without requiring JavaScript expertise.

Constraint: Components needed to be installable via pip and testable in isolation — the data team's workflow was Python-first, and anything that broke that pattern wouldn't get adopted.

CI/CD Pipeline

With the data team building applications, deployment needed to be automated and safe.

Narona Data set up a CI/CD pipeline that handled deployment across local, staging, and production environments. The pipeline included split testing and blue-green deployment strategies — enabling the team to ship with confidence without requiring ops support for every release.

Why blue-green: The client's data applications served internal users who depended on them for daily work. Zero-downtime deployments were important for trust — if an app went down during a deploy, the team would lose the credibility they were trying to build.

Templates & Dev Environment

With the platform and component library in place, the next phase focused on making the data team productive.

Application Templates

Polished Streamlit templates that new applications could be scaffolded from. These enforced consistency across apps — authentication, layout, error handling — so developers focused on business logic, not boilerplate.

VS Code Devcontainer

A custom development environment for interactive testing of multiple front-end and back-end components simultaneously. Each team member received the environment and hands-on training.

Why devcontainers: The data team's prior development workflow was notebooks and scripts. They needed a structured environment that supported component testing, hot reloading, and multi-service debugging without requiring them to become full-stack developers.

This phase was critical for adoption — a platform nobody uses is worse than no platform at all.

AWS Caching Layer

After initial rollout, the client wanted to scale further. Streamlit server resources and warehouse query costs were the bottleneck — every new user session hit the data warehouse directly.

Narona Data extended the platform by offloading caching and session management to AWS S3 and ElastiCache. This decoupled application performance from warehouse query volume.

Why S3 + ElastiCache: S3 handled large result-set caching cheaply, while ElastiCache provided fast session state management. Together they meant applications could scale with users without proportional cost increases — the exact cost spiral the client was trying to escape.

Platform Live

The data application platform went live and shifted the data team's output from dashboards to interactive applications.

What Made It Work

Three factors combined:

1. Building on existing infrastructure — Kubernetes was already there. No new infra spend, familiar ops patterns.
2. Matching the team's skills — Streamlit + Python meant zero language-learning overhead. The security and deployment layers were the hard engineering; the application framework was deliberately easy.
3. Enablement alongside platform — Templates, devcontainers, and training meant the team was productive from day one, not three months later.

The data team went from defending their BI spend to demonstrating clear ROI through interactive tools that business units actually used.