As part of building Tuist, we get to interact with and learn from products and tools that are everyday tools when developing web services. One of those tools is Fly.io, a platform where we deploy our services.

There was one pattern in Fly.io that I liked a lot and that gave us an idea for an approach we could take at Tuist to give developers a new interface to their data. Every app in Fly comes with a read-only Grafana dashboard where you can explore metrics from your service like network requests, memory usage, and CPU usage. It's insanely convenient because without it, you'd need to deploy your own Grafana instance and set up your project to collect, standardize, store, and present the data in your own Grafana instance. It's a lot of work that someone takes off our plate. And the best of all is that they also provide a Prometheus-compatible endpoint to poll the data into your own dashboard as a way of extending their read-only dashboard, and their dashboard as JSON, since Grafana dashboards follow a standard schema.

Why is this a cool idea for Tuist, you might guess? Well... at Tuist we are collecting data from your projects and the interactions with them (e.g., builds and test runs). We standardize the data and persist it in a Tuist-managed ClickHouse instance so that you don't have to do that yourself. We also provide a dashboard where we surface most, but not all, data. And this is a problem, I believe. You should have access to all your data in two ways. First, via an API. Most of our API domains are write-only. The CLI pushes data, and our dashboard is a presentation layer. But this is something that we'll change as we build clients for that data beyond the dashboard, for example, our iOS app. Second, you should be able to consume the data via a more complete dashboard, and this is where the idea of Grafana comes into play.

We are thinking about drawing from Fly's idea to provide every Tuist project with a Grafana dashboard that reads the data from our ClickHouse instance. Think of our dashboard as simple analytics, and the Grafana version as an advanced and more flexible version of it. An escape hatch where you can do more than what you get from our dashboard. And you might wonder... why not build the dashboard ourselves? The answer is simple: Because we can't build a better dashboard than Grafana. Dashboards are their business, it's something that they've done forever, and when you try the product, you notice it right away. Building dashboards is not our business, and throwing resources at matching Grafana's experience is the worst use of our resources. Our business is to collect and standardize the data—something no one has done before in the app development space, or at least not in the domains we are currently moving in, developer productivity—and then provide you with tools to get the most out of our data, from a Grafana dashboard to optimizations and insights to improve your dev environment and apps.

I did some experimenting yesterday, and I don't think it would take a lot of effort to pull this off. I've already deployed a Grafana instance at https://metrics.tuist.dev, which I connected to our ClickHouse. Our server already supports OAuth2 thanks to the amazing Boruta Elixir library, which means users can log in smoothly using their Tuist identities. One click on the Tuist dashboard, and you get taken straight to the dashboard in Grafana. We'll have to implement logic for syncing the tenants, permissions, and the dashboard, but with their API, I don't think it'll be a lot of work.

Something also amazing about going down this path is that the schema of Grafana dashboards is standardized. Which also means you can tell LLMs: here's the schema of the data I have access to, and taking into account the schema of Grafana dashboards, please build a dashboard to get particular insights. And this is something you can apply not just to developer metrics like build times, but also product metrics, which we plan to expand to later in the year or early next year. Standards are unlocking in the world of AI, especially if they are not constantly changing and the LLMs have already gained that knowledge.

I think this is the kind of feature that will differentiate our offering among competitors as we step into new markets. We are a developer-first company, and these are the product design decisions that reflect that. Moreover, it shifts the value from the server to the infrastructure, which brings us closer to adopting a license like the Functional Source License (FSL) for the server, since customers will want to pay us for providing a fast and reliable service. As David Cramer shared in a podcast, we'll have organizations that will prefer to host it for free and go through the pain, and that means they won't pay for the product, but those customers that are not paying for the product are not paying your competitors either, and they are closer to becoming your customer. That's the place where we want to be as a company, especially as we expand to new markets where all the solutions are closed source.