I run a small SaaS. Not a team — just me. One developer managing a GitHub repository, a Vercel deployment, a Supabase database, a Stripe account, a Sentry project, and a Linear board. On a good day I check all of them once in the morning and forget about them. On a bad day I have twelve tabs open and I am still not sure what is actually wrong.
That is the problem. Not that the tools are bad — most of them are very good. The problem is that none of them talk to each other. Each one has its own dashboard, its own alert system, its own mental model for what "healthy" looks like. To understand the state of your stack at any given moment, you have to hold all of it in your head simultaneously.
The twelve tabs problem
I counted once. On a Friday afternoon when something was behaving strangely, I had twelve browser tabs open across six services. I was not fixing anything in those tabs — I was just looking. Checking if there were errors in Sentry. Checking if the last Vercel deployment had completed. Checking if the Supabase database was near its limits. Checking if Stripe had flagged any failed payments.
Every one of those checks answered one question: is everything okay? And every one of them required a login, a navigation, a context switch. The cost is not just the time — it is the cognitive load of holding twelve different visual languages in your head at once.
Why read-only is the right constraint
The obvious solution is a unified dashboard. There are a few of them, but most try to do too much — they let you take actions across services, configure things, manage deployments. That sounds useful until you realize it also means giving a third-party tool write access to your production infrastructure.
The right constraint, I decided, was read-only. Not because write access is inherently bad, but because the problem I was trying to solve was purely about visibility. I do not need to roll back a deployment from my dashboard — I need to know that a deployment happened and whether it succeeded. I do not need to query my database from a unified surface — I need to know its size and whether it is responding. Read-only makes the problem smaller, the security posture better, and the product easier to trust.
What dev-views actually is
dev-views pulls live data from each service's API — deployments from Vercel, errors from Sentry, usage from Supabase, revenue from Stripe — and shows them in a single surface. It refreshes automatically. It never writes anything. It requires only the minimum read scopes each service supports.
The goal is to answer "is everything okay?" in ten seconds, without opening a single additional tab.
It is in active development. If you are a solo developer who recognizes this problem, join the waitlist. The integration survey also helps us understand which services matter most to you — that data is feeding the roadmap directly.