The dashboard is becoming the app

I've built more dashboards in the past few months than in the several years before that combined. Some started as simple reporting tools. Others got surprisingly sophisticated, pulling information from different systems, analyzing it, and giving me a much better view of what was happening across the business.

Something happened along the way: I started adding functionality. At first it was small things, like filtering data, drilling into records and asking questions about what I was seeing. Then I started thinking about what I actually wanted to do with the information.

If a project was behind schedule, why couldn't I investigate it right there? If someone was overallocated, why couldn't I look at alternatives and make the change? If a renewal was at risk, why couldn't I pull together the account history, find the problem and start whatever needed to happen next?

At some point I realized I was building applications. They didn't have endless menus, screens and configuration options. They were focused on the work I was trying to get done, and I'm beginning to think this could change how we use enterprise software.

We look at the business in one place and run it somewhere else

Think about how most business dashboards work today. You open Power BI, Tableau or some other reporting tool and look at revenue, pipeline, utilization, project performance, retention or whatever else matters to your role. You notice something that needs attention. Then you leave the dashboard.

You open Salesforce to look into the opportunity, maybe the project management platform to check delivery, then NetSuite for the financials. You send a few emails, schedule a meeting, or ask someone to update a record. The dashboard helped you find the problem, and the actual work happened somewhere else.

We've accepted that split for years: reporting systems tell us what's happening, and operational systems are where we act on it. I'm starting to question why they need to be separate. If the dashboard already knows which customer, project, opportunity or person I'm looking at, why should I navigate to another application to take the next step? Why can't the dashboard be where the work happens?

AI changes what a dashboard can be

A traditional dashboard is mostly a presentation layer. It shows information someone already decided was important: revenue by month, pipeline by stage, project profitability, utilization. That's useful, but the person looking at it still has to interpret the data, investigate the problem, decide what to do and coordinate the response. AI makes it possible to fold much of that into one experience.

Imagine opening a dashboard and seeing that delivery margins have dropped. Instead of working through several reports, you ask why. The system looks at project costs, staffing, utilization, scope changes and revenue recognition, finds the engagements contributing most to the decline and explains what seems to be driving it.

Then you ask what could be done. It weighs possible staffing changes, flags projects with unusual cost patterns, and shows where stepping in might help. If you decide to act, it can start the right workflow, within the permissions and approvals you've set. At that point the dashboard is helping you investigate, decide and execute, and that looks a lot more like an application than a chart.

The application doesn't have to be built first

Traditionally, building business software meant defining requirements, designing screens, creating workflows, developing integrations and eventually releasing an application. If someone needed something new, they submitted a request, developers evaluated it, and it went into a backlog. Maybe it got built. Maybe it didn't.

What if the starting point is the dashboard itself? You're looking at the business, you see something that needs attention, and you realize you need a capability that doesn't exist yet. So you build it, or more and more often, you ask an AI development tool to help.

That's been one of the more surprising parts of working with Claude. I can start with a simple dashboard, connect more data, add functionality, and gradually turn it into something that supports an actual business process. A reporting view turns into a management tool, then a workflow, then an application, and I never had to start by buying another software product.

There's still a difference between building something inside an AI environment and deploying a reliable application a whole organization can use. Authentication, persistent data, testing, security and operational support still matter. But the development process is changing, and the distance between spotting a business need and building something useful to meet it keeps shrinking.

Imagine running a professional services company this way

This is where the idea gets compelling for me. A professional services business has a fairly simple set of operating questions. Are we generating enough pipeline and winning the right work? Do we have the people to deliver it? Are projects on schedule and profitable? Are customers satisfied, and are renewals at risk? Answering them usually means pulling information from CRM, finance, resource management, project delivery and service management systems.

Now imagine a single operating dashboard. You open it in the morning and see the health of the business: revenue, pipeline coverage, delivery capacity, project profitability, upcoming renewals and operational risks. Every part of it is actionable.

You see an opportunity expected to close next month, select it, and immediately see whether delivery has the capacity to take on the work. A project is trending over budget, so you ask the system to investigate, and it compares actual labor costs with the original delivery assumptions. A renewal is coming up, and the dashboard pulls the account history, service performance, open issues and commercial terms into a renewal briefing. You hit a staffing conflict, and it looks at who's available and proposes alternatives. When a decision has to be made, you can act on it without jumping between applications.

I don't mean a prettier executive scorecard. I mean an operating environment built around the decisions and actions it takes to run the business.

Don't we still need the underlying applications?

Probably, at least for now. This is where the idea meets the broader debate about headless software and AI agents. A dashboard can become the main interface without replacing the systems underneath. Salesforce might still hold customer records, NetSuite might still handle financial transactions, and a project management platform might still keep the delivery schedule.

The dashboard connects to those systems through APIs and other integrations, and agents help coordinate work across them. That alone is a meaningful improvement: instead of learning and navigating several applications, people work in one environment organized around what they're trying to accomplish.

There's another possibility, though. If the dashboard already handles account management, opportunity tracking, pipeline forecasting and customer reporting, do you need a separate CRM interface? And if the data, business rules and workflows can live in your own environment, do you need the CRM platform at all? Maybe you do. Maybe you don't.

That's where the economics get interesting. At first the dashboard is a better way to use existing software. Over time it might replace parts of that software, and eventually some companies may decide certain applications aren't worth maintaining or paying for. The dashboard becomes the visible part of a much more flexible operating architecture.

This isn't just a theory anymore

You can see pieces of this shift across the industry. Tableau has been expanding its agentic analytics, connecting business context, conversational analysis and actions across enterprise systems. Amplitude has introduced agents that monitor product behavior, investigate changes, recommend responses and support actions, rather than only producing reports. And AI development environments are making it easier to build custom dashboards and interactive business tools outside the traditional development process.

These aren't the same thing, and none of them proves that dashboards will replace enterprise applications. They do point in a similar direction. The line between analytics, software interfaces and operational workflows is blurring, and the dashboard can be the start of execution instead of the end of the information process.

There's a problem with this idea, too

Turning every dashboard into an application could create a mess. One reason companies invest in enterprise platforms is consistency: controlled data, defined permissions, reliable workflows and clear accountability. If every department builds its own AI-powered dashboard that can change business records, you could recreate the same fragmentation you're trying to remove, only faster and with more risk.

Picture a sales dashboard and a finance dashboard calculating revenue differently. Or an agent updating an opportunity based on a wrong reading of a contract. Or someone building a staffing tool that ignores commitments recorded somewhere else. These are exactly the problems enterprise architecture and governance exist to prevent.

Abandoning those disciplines isn't the answer. Separating the experience from the controls underneath is. The dashboard can be flexible, the interface can change, and AI can help generate new functionality, while the data definitions, business rules, permissions and transaction controls stay consistent. A financial transaction still goes through an approved financial process. A staffing change still respects availability and authorization. A customer record still has a clear system of record. That way the dashboard can become the application without becoming an uncontrolled pile of AI-generated workflows.

The dashboard might not even look like a dashboard

Maybe we use the word dashboard because it's the closest thing we have for what's emerging, and the experience itself could get much more dynamic. Today we design dashboards in advance. Someone decides which charts, tables, filters and metrics appear, based on what they think people will need. What if the interface adapted to the work instead?

A sales leader opens it and sees pipeline, forecast risk and account activity. A delivery executive sees project performance, capacity and margin exposure. A CFO sees cash flow, revenue recognition, profitability and financial exceptions. They're all working from the same business information, organized around their responsibilities, and when they need something different, they ask for it. The system builds the view, pulls the information and offers the relevant actions.

At that point it's less a static dashboard and more a business interface that assembles itself around the problem you're solving. Not every interaction should be conversational. Sometimes a chart is the fastest way to understand something, and sometimes you need a table, a form or a traditional workflow. The advantage is having those available when they help, instead of forcing every task through a predetermined application structure.

What happens to the traditional application?

This is the question I keep coming back to. For decades, vendors designed applications around collections of features. You buy the application, learn its interface, configure its workflows and adapt your processes to fit. If dashboards and AI-driven interfaces can provide the specific functionality people need, the application starts to fade from view. Its underlying capabilities may still matter enormously, but the interface matters less.

Once the interface stops being the main reason people use the software, it gets easier to question the rest of the subscription. Do we need the entire application, or every licensed user? Could some capabilities be replaced with simpler services, or built ourselves? Would one unified operating environment serve us better than several specialized applications?

There's no single answer for every company, but I think those questions will come up more and more, and for enterprise software vendors that's a meaningful change. The competition may shift from who has the best application interface to who provides the most valuable underlying capabilities, the most reliable data, and the easiest way for people and agents to get work done.

What I'm starting to realize

I thought I was just getting better at building dashboards. The more functionality I add, the more I question why the applications behind them need to exist in their current form. If I can see a problem, understand it, weigh my options and start a response from one place, why should I have to open another application? And if I can build that experience around how my company actually operates, why should I be limited to the workflows a vendor decided to provide?

The dashboard won't replace every application, and businesses shouldn't start rebuilding their entire technology stacks. Mature enterprise platforms still hold a tremendous amount of value. But the dashboard's role is changing. For years we built dashboards after the applications were in place, sitting on top of our systems to help us understand what they were doing.

I'm starting to see that relationship reversed: start with the decisions people need to make and the work they need to do, build the experience around that, then connect or create the capabilities underneath.

“Instead of building dashboards to understand our applications, we may start building applications around our dashboards.”

If that happens, the dashboard stops being only the place where we look at the business. It becomes one of the places where we run it.