Why we started Waydev?

I built my first software product in 2007. Since then, I have created and launched dozens of products and spent most of my professional life working alongside software engineers.

Across different companies, teams, and products, I kept running into the same problem.

We had analytics for almost everything else. Marketing had Google Analytics. Sales had CRMs. Finance had financial systems. Customer success had its own platforms and dashboards.

But when it came to software engineering, some of the most important questions were still answered through meetings, spreadsheets, status updates, and intuition.

I kept asking myself a simple question.

That question eventually became Waydev.

The problem was never a lack of engineering data

Software development generates enormous amounts of data. Every pull request, commit, code review, deployment, issue, incident, and release leaves a digital footprint.

The problem was that the data was fragmented across Git repositories, project management systems, CI/CD tools, and dozens of other platforms.

Engineering leaders had access to the raw information, but turning it into something useful required hours of manual analysis.

You could inspect repositories. You could go through Jira tickets. You could ask every engineering manager for an update. But by the time you assembled the full picture, the information was often already outdated.

Intuition is valuable. Experienced engineering leaders develop extremely good instincts. But intuition should be supported by evidence, not forced to replace it.

The first idea behind Waydev

The first version of Waydev started with a simple observation: much of an engineer’s work already existed inside the systems where software was being built.

Instead of asking engineers to manually report what they were doing, software could analyze the systems where the work was already happening, including GitHub, GitLab, Bitbucket, and Azure DevOps.

That meant engineering leaders could understand patterns across their development process without adding another layer of administrative work for engineers.

This was the foundation of Waydev.

Engineering performance cannot be reduced to commits

Counting commits, lines of code, or pull requests cannot tell you whether an engineering organization is performing well.

More code does not necessarily mean more value. One engineer might solve an important problem with 20 lines of code while another changes thousands. A team might increase development activity while creating more rework, technical debt, or production problems.

That realization changed how we thought about Waydev.

We were not trying to build a tool for counting engineering activity.

From engineering activity to Engineering Intelligence

Over time, the questions customers asked us became much more sophisticated. Engineering leaders did not simply want to know what happened. They wanted to understand why it happened and what to do next.

• Why did it happen?
• Where are the bottlenecks?
• Which teams need help?
• What is affecting developer experience?
• Are releases becoming more predictable?
• How are engineering resources being allocated?
• Which initiatives are consuming the most capacity?
• What should we change next?

Answering those questions requires more than a dashboard. It requires connecting data from across the software development lifecycle and turning that data into context engineering leaders can actually use.

Today, Waydev brings together engineering signals across delivery, planning, developer experience, resource allocation, AI adoption, and business outcomes.

Engineering organizations can use DORA Metrics to understand delivery performance, analyze Developer Experience, identify bottlenecks, understand how resources are allocated, and create a shared view of engineering performance across leadership and engineering teams.

Then AI changed software engineering again

The arrival of generative AI has made the original problem we started Waydev to solve even more important.

Engineering organizations are now investing heavily in AI coding tools and AI agents. Engineers can generate, review, test, and modify software faster than ever before.

But faster code generation creates a new set of questions for engineering leaders.

Buying AI licenses is easy.

This is why Waydev now connects AI Adoption with AI Impact and the broader software delivery process.

The goal is not simply to measure how often engineers use AI. The goal is to understand what changes after they use it.

The question has changed, but the mission has not

In 2018, the question was:

Today, the environment is far more complex.

Software is being created by a combination of humans, AI coding assistants, and increasingly autonomous agents. Engineering organizations operate across hundreds or thousands of repositories, projects, teams, tools, and initiatives.

The new question is:

That is the problem we are solving with Waydev.

Measurement should help engineers, not police them

The purpose is to understand systems.

Where does work get stuck? Where are engineers spending unnecessary time? Which processes create friction? Where is technical debt slowing delivery? Which investments are creating results?

Good Engineering Intelligence should help leaders remove obstacles and create an environment where engineers can do their best work.

What I wanted in 2007 still doesn’t fully exist

When I started building software products, I wanted the same clarity for engineering that I could get from analytics in every other part of the business.

I wanted to open one place and understand what was happening.

We have spent years getting closer to that vision.

The technology has changed dramatically since we started Waydev, but the core idea has remained remarkably consistent.

That is why I started Waydev.

And with AI transforming how software is built, I believe that mission is more important now than when we started.