The SaaS model solved a real problem: specialized software for every business function, accessible via subscription, no infrastructure required. But the cumulative effect of ten years of SaaS adoption has created a new class of operational problem that most teams do not have a systematic way to manage.
The Average Company Uses 130+ SaaS Tools
According to Productiv's 2023 SaaS Management Index, the average mid-size company runs between 130 and 137 distinct SaaS applications. Enterprise companies run more.
Each application has its own dashboard. Its own notification channel. Its own billing cycle, admin interface, API, and access control model. Each adds a new login surface for security. Each adds a new vendor relationship to manage. Each adds a new integration point that breaks when either side updates.
The number has grown faster than organizational capacity to manage it. IT and platform engineering teams that once managed 20-30 tools now have visibility into a fraction of what is actually running.
The Real Cost of Fragmentation
The cost of SaaS sprawl is not primarily financial -- though uncapped license usage and dormant subscriptions are a real drain. The larger cost is operational.
Context switching is the most immediate tax. Developers and operators maintain mental models of five, ten, sometimes fifteen dashboards. Every time a metric changes or an alert fires, someone has to open the right tool, navigate to the right view, and interpret the signal. Microsoft research on context switching costs suggests this carries a 15-25 minute recovery time per switch for deep-work tasks. Multiply that across a team and a week.
Missed alerts happen because the signal volume from 130+ tools exceeds human processing capacity. Slack channels fill with notifications from Datadog, PagerDuty, Sentry, Linear, GitHub, Vercel, Stripe, and a dozen others. Critical alerts get buried. Teams respond reactively rather than proactively.
Duplicated data is the quiet operational cost. Customer data lives in the CRM, the support tool, the billing system, and the analytics platform simultaneously. Keeping it consistent requires either manual synchronization or complex ETL pipelines. Neither scales.
Lingering access accounts from former employees are an underappreciated risk. When someone leaves, removing their access across 130 applications requires a coordinated checklist. In practice, access persists in the tools that do not have automated provisioning in the HRIS integration. Former employees retain access to production systems, customer data, and financial tooling longer than intended.
Why Integrations Do Not Fully Solve It
The natural response to fragmentation is integration. Tools like Zapier, Make (formerly Integromat), and n8n have grown enormously by solving point-to-point connection problems. Connect A to B, trigger action C when event D fires.
But integration platforms solve data movement, not visibility. After implementing a Zapier workflow that syncs your CRM to your billing system, you still have two separate dashboards showing two separate views of what is happening. The data moved. The visibility problem did not.
You can connect your monitoring tools to Slack. Your incidents will flow into a channel. You will still context-switch to three other dashboards to diagnose what the incident means and what the remediation requires.
The integrations address symptoms. The underlying problem is that there is no unified operational canvas across the SaaS stack.
What a Unified SaaS Canvas Would Look Like
The concept is straightforward: a single interface that aggregates the signals that matter most from across your SaaS stack, normalized into a consistent view.
The value is in what you can see at once:
- Active applications and usage: which tools are actually being used, by whom, and how often -- versus which subscriptions are running but dormant.
- Spend visibility: aggregate SaaS spend in one view, with per-seat cost breakdown and renewal timeline.
- User access status: cross-application view of who has access to what, with offboarding status for departed team members.
- API health: uptime and latency from the SaaS APIs your applications depend on, surfaced before your customers experience the degradation.
- Security events: failed authentication attempts, unusual access patterns, and permission changes across the stack, with unified alerting.
The implementation challenge is real. Every SaaS application exposes a different API structure, authentication model, and data schema. Normalizing signals across 130 applications requires significant integration work and ongoing maintenance as APIs change.
But the value of solving that problem -- particularly for engineering and platform teams managing complex SaaS stacks -- is significant enough that we think it is worth building.
We're Validating Interest for StackLens
StackLens is a product concept we have built a landing page for, but have not started building yet. We are in the demand validation phase.
The reason we build landing pages first is deliberate: product development is expensive. Building the wrong thing at production quality wastes months. The landing page test tells us whether the problem resonates enough to justify the investment.
If you recognize the operational pain described in this post -- if you have ever said "I need to check five dashboards" or spent time tracking down access during an offboarding -- we want to hear from you.
Waitlist members will get early access and direct input into the product roadmap. We are not building until we know who we are building for.
We are running a demand validation experiment: 16 product ideas, 16 landing pages, build only what gets real traction. See the full set at kunstudio-labs.pages.dev.
Top comments (0)