Every product starts somewhere. For Drupal Scan, that somewhere is a combination of years of experience, a conversation at a conference, and two client projects that happened at exactly the right time.
Let me tell you the story.
It Started with Audits
I've been working with Drupal for over 10 years now. A good chunk of that time has been spent doing audits. Performance audits when clients come to me saying their site is painfully slow. Technical SEO audits when a site isn't ranking as expected. Code reviews when an SEO agency tells a client there are technical issues but has no idea how to fix them.
Over the years, I built some simple bash scripts to help me with this work. Nothing fancy, just quick checks for the most common problems I kept finding over and over again. They saved me time and gave me a starting point before diving deeper into the code.
The Conversation in Santiago
In September 2025, I attended DrupalCamp Spain in Santiago de Compostela. You know how conferences work. The talks are great, but sometimes the most valuable moments happen in the hallways between sessions, during coffee breaks, or at dinner.
During one of those conversations, I was talking with someone who mentioned they had a small script to validate very specific configurations exported to code. Just a simple tool to check things that mattered for their projects.
That got me thinking. My bash scripts were useful, but they weren't really taking advantage of all the configuration data that modern Drupal exports to YAML files. Since Drupal 8, so much of a site's setup lives in those config files. Views and their cache settings. Field configurations. Display modes. All of it sitting right there in the codebase, readable and analyzable.
What if I improved my scripts to check things like how many views a site has, whether those views have caching properly configured, whether they have pagination or are loading unlimited results, whether certain performance-critical settings are correct? That kind of deep configuration analysis was something my old scripts weren't doing.
From Bash to Something More Useful
After the conference, in October, I started working on it. I used AI to help me build a quick minimum viable product based on my existing scripts. The goal was to modify them so they could parse Drupal's YAML configuration files and generate a detailed report.
The output was ugly. Really ugly. But it worked. Given access to a Drupal project repository, the scripts would analyze the code and configurations, then spit out a report listing exactly which files and which lines had potential problems.
I was happy with the progress, but then I started talking to more people about it. And I realized I had a problem.
The Repository Access Problem
My scripts worked great for my own clients because I already had access to their repositories. But thinking about this as a potential SaaS product, that approach wouldn't scale.
Not every client will give you access to their repository. Some companies have security policies that prevent sharing code with external parties. And even when you do have repository access, what you see there might not match what's actually running in production. Code gets deployed, configurations get overridden, things diverge.
So I asked myself: how viable would it be to turn all of this into a Drupal module instead?
A module that you install on the site itself solves all these problems. Once installed, it has access to everything. The codebase. The exported configurations. The configurations stored in the database. And it can run on any environment: local, development, staging, production. You get the real picture of what's actually there, not what the repository says should be there.
Two Clients, Perfect Timing
Sometimes timing just works out. At the end of 2025, I had two different clients ask me for similar things. One needed a code audit. The other needed me to review the frontend work their agency was doing and identify performance improvements.
I used my new module for both projects. And it was incredibly useful, but it also showed me the gaps. My code was too specific to my own projects and past clients. It was throwing too many false positives for things that weren't really problems, just different approaches that made sense for those particular projects.
So I spent time refining the detection logic. Things that I was initially flagging as errors or warnings, I recategorized as notices. Because sometimes a configuration that looks wrong is actually intentional for a specific use case. The tool needed to be smarter about that.
What the Tool Does (and Doesn't Do)
I want to be honest about what this tool is and isn't. Drupal Scan gives you a surface level analysis. It detects potential issues and flags things worth investigating. But it doesn't replace expert review.
In both client projects, the tool gave me a starting point. It generated a list of things to look at. Then I, as a senior developer with years of experience, went through each item to determine if it was a real problem or a false positive. I documented my findings, explained the context, and had meetings with the development teams to discuss solutions. Because finding a problem is only half the work. Understanding what it means for that specific project and how to fix it is the other half.
Why a Dashboard Makes Sense
After using the module on these projects, I realized something. Having a list of issues in the Drupal admin is fine for a single site. But what if you're managing ten sites? Or twenty? Or fifty?
That's when the idea of a centralized dashboard clicked. One place where you can see the health of all your projects. One login instead of checking each site individually.
And then there's the time dimension. An audit is a snapshot. You run it once, find problems, fix them, and move on. But what happens two months later when a developer installs a new module that introduces a performance issue? Or when a junior developer changes a configuration without understanding the implications?
Having periodic automated checks means you catch these things before they become real problems. You don't have to wait until a client complains that the site is slow or until Google drops your rankings.
Building Something Useful
All of this combined is what led me to build Drupal Scan. Years of audit experience. A conversation at DrupalCamp that sparked an idea. The realization that repository access wouldn't work for a SaaS model. Real client projects that validated the approach and helped me refine the detection logic.
Agencies managing multiple Drupal sites need visibility. Clients investing in Drupal projects deserve transparency about the health of their investment. And developers need tools that help them catch issues before they escalate.
That's what I'm trying to build. We'll see if others find it as useful as I do.