Know the state of your code, every sprint.

Every survey grades the code by the same published rules, so the scores from one sprint and the next can be compared. The team sees the score for the whole product and for each area of it, such as security or architecture, and whether each one moved up or down. Each score can be opened to see the findings behind it and the rule each one is measured by, so the team can discuss in the retro exactly what changed in the code and why the score moved.

Time to improve the code is hard to plan when the only argument is that the code feels hard to work in. A survey shows which part of the code has got worse over the last several surveys, with the file and line of every finding behind it. That gives the team a concrete reason to set time aside for the work, next to new features. When the work is done, the next survey shows whether the score went up, so the team can show that the change improved the code, not just that it still compiles. That result makes the next refactor easier to agree on.

When a product is divided into separate areas, such as orders, payments and users, every survey draws a diagram of them from the code itself, showing how they depend on each other and where the boundaries between them are. Areas that are tied together where they shouldn't be are marked in red, and each area is coloured by how many problems the survey found in it. Nobody has to keep the diagram up to date by hand, so it is as current as the last survey, including for new team members. The architecture is graded in every survey, with or without a diagram.

Every survey ranks its findings by how much each fix is expected to raise the score for the work it takes, so the first items on the list give the most improvement for the least work. The survey also names the weakest area and what would raise it, which gives the lead an order for the backlog that is easy to explain. Each finding comes with the rule it breaks, the file and the line. Developers can work through the list themselves, or give it to a coding agent through the standard way agents connect to tools (MCP). The agent then spends its time on the problems that matter most, instead of on small things like formatting.

Most products are built in more than one language, such as an API in C#, a front end in TypeScript, a background worker in Go and a data job in Python. Checking them usually takes a separate tool for each language, each with its own rules, and the results are hard to add up to one answer for the product. Watchdog grades every part by the same rules and combines them into one score. Repositories that are shipped together can be surveyed as one product, and the architecture diagram shows how the parts connect across languages. When several services live in one repository, each service also gets its own score, so the team can see that the product as a whole is fine while the billing service is not.

The survey reads the history of the code and finds the parts that only one or two people have worked on recently (the bus factor). Those parts would be the hardest to take over if someone left, and knowing where they are lets the lead plan for it, for example by having a second person work on them. The same history shows the files that change often and are hard to read (hotspots). Those are the files the team works in most, so problems there cost the most. The survey also gives a rough estimate of what it would cost to build the code again from scratch, in euros and working years, which helps the lead explain what it would take to replace it. All of this comes with the survey, so no separate tool is needed to read the history.