Every developer has 47 dashboards open. Here's why that's actually fine.
The 'minimalist workflow' people are wrong about this one. Modern dev work is a portfolio of services and the job isn't fewer tabs — it's faster traversal. A contrarian take on tab overload, focus, and what actually helps.
Open your browser right now. Count the tabs.
If you're a working developer in 2026, the number is somewhere between 20 and 80. Maybe more. There's a Vercel tab. A Supabase tab. A Stripe tab — probably two, one for test and one for live. A Linear tab. A GitHub PR. A docs tab. Three Notion tabs you forgot you opened. A YouTube video on mute. Two Claude conversations.
Every productivity blog of the last decade has told you this is a problem. "Tab overload!" "Focus is a finite resource!" "Close tabs to think clearly!"
I don't think they're right. I think the 47 dashboards are a feature, not a bug, of how modern dev work actually happens. The thing that needs to change isn't the number of tabs. It's how fast you can move between them.
The minimalism story is wrong for this kind of work
The "fewer tools = better focus" idea comes from a real place. Cal Newport's Deep Work, the early Basecamp blog, the whole "essentialism" movement. The pitch is: switching costs are real; multitasking is a myth; the people who do great work do it by closing everything else.
That's true for the work of writing the code itself. When you're in flow, in a single file, debugging a single function — yes, close the tabs. Yes, full screen. Yes, do the deep thing.
But that's maybe 30% of a working day. The other 70% is:
- Cross-referencing the Stripe webhook payload against your database schema
- Checking a Vercel deployment log because something failed at build time
- Pulling the latest from a Linear issue while you're mid-PR
- Confirming the Resend API responded 200 by looking at the email log
- Looking up the Anthropic rate limit because Claude just 429'd
- Checking whether Cloudflare propagated your new DNS record yet
None of that is "deep work." All of it is essential to shipping. And all of it requires being one click away from a dozen different services at once.
The 47 tabs are how that one-click-away gets cached.
A modern stack is a portfolio of services
Compare 2014 and 2026.
In 2014, a typical solo dev shipping a web app needed: a server (Heroku), a Postgres database (same), a payment processor (Stripe), an email sender (Mailgun or SES), and Google Analytics. Five services. Five dashboards. Mostly opened once a month.
In 2026, the same dev needs: a deploy target (Vercel), a database (Neon or Supabase), object storage (R2), an LLM provider (OpenAI), a second LLM provider (Anthropic), an LLM router (OpenRouter), auth (Clerk), payments (Stripe), email (Resend), error tracking (Sentry), product analytics (PostHog), feature flags (also PostHog), DNS (Cloudflare), an issue tracker (Linear), and code hosting (GitHub).
Fifteen services. Easily. And that's a minimal setup — no Twilio, no Segment, no Datadog, no Notion, no Slack, no Discord.
The reason is real: every one of those is doing a job that a 2014 dev would have built in-house or done without. The trade is "fewer services, more custom code" vs "more services, less custom code." The modern answer is the second one. The economics moved that way and they aren't moving back.
So the surface area is bigger. Way bigger. Pretending it isn't doesn't make it not.
The right metric isn't number of tabs. It's traversal time.
The thing minimalism gurus get wrong: they treat dashboards like obligations. As if every tab is something you're failing to clean up.
I'd flip it. Every dashboard is a load-balanced bit of memory. Stripe knows about your payments so you don't have to. Resend knows about your email so you don't have to. Sentry knows about your errors so you don't have to. Each dashboard is a piece of your application's brain that you've offloaded to a SaaS.
The job of the developer is not to avoid opening those dashboards. It's to traverse them faster than the alternative — which would be writing custom code, reading raw logs, or losing context.
If "go check the Stripe webhook payload" costs you 8 seconds, that's fine. You'll do it a dozen times a day. If it costs you 90 seconds (find the tab, log in again, click through nav, scroll, search), you'll avoid doing it, and now you're flying blind on your own system.
The metric that matters: how long, from "I need to see X" to "I am looking at X."
What actually helps
Three things, in order of leverage.
1. Cross-app ⌘K
The single biggest improvement to my workflow over the last year has been treating ⌘K as universal. Every app I use has its own. The moment I added a layer that crosses apps — type "stripe webhook", land on the page — the traversal time dropped to about two seconds for any service in my stack.
This is the thing devlinkspad does. There are other ways to get the same effect (Raycast extensions, browser custom search engines, well-organized bookmark folders) and they all work. The point isn't the specific tool — it's the abstraction.
2. Tab grouping by project, not by tool
I used to organize tabs by service: all the Stripe stuff on the left, all the Vercel stuff in the middle. That's wrong. Group by project — all the tabs for "client A" together, all the tabs for "my side project" together. Tabs are a working memory, and working memory is per-task, not per-tool.
Arc, Chrome tab groups, Firefox containers, whatever. Pick a mechanism. Stick with it.
3. A small persistent dashboard surface
This is the underrated one. Most dashboard work is "glance, confirm, go." You don't need to be in the Stripe dashboard for two minutes; you need to see a number on it and leave.
A small docked side window — Raycast's window mode, devlinkspad's Sidekick, an Arc split view, whatever — lets you keep an always-visible surface to the second-most-needed dashboard while your main window stays focused on the actual work. Cuts an enormous amount of context switching.
The 47 tabs are a portfolio metaphor
A portfolio investor doesn't apologize for holding 47 stocks. They have 47 stocks because the right amount of diversification for their goals is 47 stocks. The tools they use to manage the portfolio (rebalancing software, alerts, etc.) make 47 manageable.
A 2026 developer's stack is a portfolio. It's not a moral failure to have 15 SaaS subscriptions and 47 open tabs. It's the consequence of the work being more horizontal than it used to be.
The job is to manage the portfolio well. Fast traversal. Good keyboard ergonomics. Caching the dashboards you use most in tabs. Knowing where the deep pages live. Not feeling guilty about any of it.
What I wish more people would say
The "back to basics" / "delete your dashboards" / "minimalism" framing assumes that the right number of services is small. That assumption made sense in 2014. It doesn't anymore. The right number of services is "whatever number lets you ship the thing you're trying to ship without writing the parts that aren't your competitive edge."
For most working developers in 2026, that number is high.
The leverage isn't in fewer dashboards. It's in faster movement across the ones you have. That's where the design effort should go — and that's the part most productivity advice still misses.
If you keep losing dashboard pages, that's literally what devlinkspad is for. ⌘K → devlinkspad.com.
Related:
Press ⌘K. Every dashboard, one keystroke away.
Try devlinkspad — free