A CTO showed me a dashboard last month. His team had built it. Developer metrics pulled from GitHub, looked clean, worked fine.
I asked the obvious questions:
Are you launching it to the org? Does it connect to Jira? You mentioned surveys, are those wired in?
“Yeah, the surveys would be easy to add. We’ll get to it.”
They didn’t get to it. They won’t.
And that’s the pattern I keep seeing right now, the same one I saw in the 2010s, just with a new soundtrack:
“We can build it ourselves. AI is killing SaaS anyway.”
Maybe some tools will disappear. But here’s what I think most people are missing:
Everyone’s measuring AI by how much it lets them build.
The real question is how much it lets them stop.
Cheaper code doesn’t make building the right thing matter less. It makes building the wrong thing more expensive, because now you’re maintaining it, improving it, defending it in roadmap meetings, explaining it to the next hire. Forever. For something that isn’t your business.
I sell engineering analytics, so yes, I have a stake in this argument. But that’s also why I notice the pattern earlier than most: the teams who build their own version almost never finish it. The dashboard ships. The integration doesn’t. The survey loop doesn’t. The thing that would have actually changed how the team works, that’s the part that gets deprioritized the moment a real customer problem shows up. As it should.
The best engineering leaders I work with don’t ask “can we build this?” anymore. The answer is almost always yes now.
They ask:
What am I going to stop building this quarter?
Here is a simple 3 questions to ask before you build the next one
1. Will this still get attention in six months?
Not “will we finish v1.” Will someone own it, improve it, defend its roadmap slot against the next shiny thing? If the honest answer is no, you’re not building a tool. You’re building a prototype that will quietly rot in production.
2. What’s the second integration?
Most internal tools work for one data source. The value shows up at the second. GitHub metrics alone are vanity. GitHub plus JIRA plus survey data tells you something. If your team can articulate the first integration but waves vaguely at the second (”we’ll get to it”), the project is already dead. They just don’t know it yet.
3. If a vendor solved this for the cost of one engineer-month, would you still build it?
“can we build it cheaper” (you probably can’t, once you count maintenance). The question is whether building it gives you a strategic advantage your competitors can’t buy. For 95% of internal tooling, the answer is no. It’s table stakes pretending to be differentiation.
If the answer is yes, build it. Own that capability. If the answer is no, you already know what to do.

















