Reports VS Dashboards
Back when I worked at Setu building the Data Business, I noticed something interesting. When the dashboard isn't your core product, it becomes 100 times harder to get traction. On the other hand, sending a daily email report is much easier and helps you build the foundation for dashboard adoption.
Dashboards are fancy. Dashboards are cool. While it’s relatively easy to build dashboards that show metrics, it’s much harder to build ones that focus on your ideal customer persona (ICP) and show metrics they’re not actively tracking or that take time to calculate.
In businesses like APIs or those with deeper integrations, the dashboard is not the product. The real product is the value your API delivers or the backend integration powering customer outcomes. Dashboards are just displays, knobs, and control panels for the core service. They become important at scale, but early on, many of these tasks can be handled through simple email exchanges.
Sometimes, it’s not even clear who the dashboard is meant for. The primary user of your API might be an engineer, but the dashboard might be more relevant to a product or project manager. In the early stages, it’s easy to assume your ICP needs everything and will use the dashboard daily. The reality is, they might check it once a week, or even once a month, and still email your support team to ask for changes.
It’s a myth that your dashboard needs to do everything. A great dashboard is minimal, self-navigating, and solves a few key problems so well that the user doesn’t feel like they ever had an issue.
To get there, though, your dashboard needs to go through several iterations. If the feedback loop is slow, feature requests keep piling up, and the dashboard starts becoming too generic. In trying to solve for everyone, you end up solving for no one.
To avoid that, we never start with a dashboard. Whenever we launch a new product, we begin with a persona-specific email report. This includes metrics tailored to help the ICP understand the value of the offering. The email goes out at the start of the day. This approach solves three problems:
-
The open rate for an email is much higher than the login rate for a dashboard, giving us an easy entry into their attention space.
-
When the ICP sees value from the report every day, it builds mindshare and increases the chances of converting a user into a customer.
-
Over time, they begin sharing details they want to see in the report. This list becomes the prioritized request set for your future dashboard.
This method keeps your product lean, aligns features with actual demand, and avoids overwhelming your engineering team.
At Panto AI, we help engineering leaders adopt code review best practices, improve developer productivity, and reduce PR merge times. Our core users are engineering leads, managers, and CTOs. We applied the same approach when building our internal dashboard, and it worked well.
We started with a report sent only to our ICP at 9:30 AM local time, wherever they were. Whether they were checking their phone, starting work, or having breakfast, they received a snapshot of everything they needed in under a minute.
The report started with basic metrics and became more specific as we learned from feedback. Each metric included a simple visual representation. Our key focus areas included:
-
Number of PRs opened and merged, average time to merge, and quickest merge time
-
Number of PR review comments added, and how many were accepted
-
Lines of code added and deleted per repository
-
Top-performing developers, along with insights into who might need support
We spent close to 60 days working directly with our customers and started gathering feedback. We shared this daily report on every sales call, every support interaction, and even with clients who were not ready to convert. The goal was to understand one thing — can this report alone be compelling enough to change someone’s mind about monetization? It might sound exaggerated, but it was an important experiment.
After collecting enough feedback, we returned to the drawing board and began designing our new dashboard.
We started with a simple, straightforward login page that allows easy sign-in with existing accounts.
The Login
We intentionally stayed away from building our own authentication system because it adds unnecessary complexity and is harder to manage. Since our product is built to work closely with version control systems, each of which supports OAuth-based login, it made more sense to rely on those.
The Landing Page
Your customer does not have time. It is helpful to assume that your ideal customer profile might be used to watching short videos and will start losing attention every 30 seconds to a minute if you are not delivering immediate value. You cannot afford churn on the landing page.
We focused on the main metrics people appreciated in our email report and brought those into the landing page. This time, we had more flexibility to make it readable, interactive, and dynamic with controls for date and time.
We also introduced a new metric that helped clients make faster decisions — a comparison of how their key metrics changed before going live with us versus after going live.
The Real Meat
Our product is a code review bot, and our ideal customer profile is the engineering manager. At a high level, they need quick access to essential metrics like the number of pull requests opened, average merge time, and overall review coverage.
When they choose to dive deeper, they require repository-level insights. If they want to go even further, they look for developer-specific pull request data, code review comments, and contribution trends.
We built this experience using a progressive disclosure UI. This approach allows us to start with a clean overview and gradually reveal deeper insights as the user interacts with the dashboard. It helps us avoid overwhelming users with too much information all at once.
By structuring our engineering manager dashboard this way, we make it easy to monitor code quality, improve review speed, and access actionable developer analytics, all in one place.
Who's Performing and Who's Not
We have access to both qualitative and quantitative code review data, which allows us to identify performance trends more accurately. Engineering managers, our core users, are often looking to recognize top performers—but equally important is identifying developers who may be underperforming.
Our dashboard enables this with a simple dropdown that displays all developers, offering visibility into individual contribution metrics, review quality, and participation levels. This helps managers make informed decisions using real developer performance insights rather than assumptions.
By surfacing this data in a clear, easy-to-navigate way, we help teams drive accountability, reward excellence, and support developers who may need additional guidance.
New Feature Request: SCA Integration
While collecting feedback from our users, an idea emerged that we felt was worth pursuing—adding Software Composition Analysis (SCA) to our product stack.
SCA aligns well with our mission of enhancing code quality and security during the pull request lifecycle. Although active development is just beginning, we have already made space for it in our dashboard and product design. This ensures a seamless rollout and smooth integration when the feature is ready.
Bringing SCA into the workflow will allow engineering managers and developers to surface open-source vulnerabilities, license issues, and outdated dependencies—right at the code review stage—making security-first development more actionable and efficient.
Security at Core
Security and trust are foundational to how we operate at Panto. One of the first steps in going live with our platform is a simple two-click integration with your version control system.
We believe the best way to build trust is by giving control back to the customer. That’s why we’ve focused on making it extremely easy for users to connect or disconnect their GitHub, GitLab, or Bitbucket accounts at any time—no complex steps, no vendor lock-in.
By prioritizing transparency and user autonomy from the start, we ensure our customers feel secure and in control throughout their journey with Panto.
Building dashboards that truly deliver value is not just about sleek visuals or loading data into charts. It's about deeply understanding your ideal customer persona, their workflows, and when and how they consume information. At Panto AI, we chose to earn that understanding before writing a single line of front-end code. By starting with targeted email reports, refining metrics through real-world feedback, and layering insights thoughtfully, we built a dashboard that engineers and engineering leaders actually want to use.
This iterative, feedback-driven approach helped us build trust with our customers and align our product experience with the real needs of engineering teams. Whether it is surfacing pull request metrics, identifying top performers, or planning for new features like software composition analysis, our focus remains the same: helping teams ship high-quality code faster without compromising control, visibility, or security.
Dashboards are not the product. Insight is. And when insights are surfaced with precision, context, and care, your product becomes indispensable.