Robert Menetray Builds DruScan to Simplify Drupal Audits

Built as a practical response to a familiar Drupal problem, DruScan helps teams review inherited, multi-team, or fast-changing projects without relying only on scattered scripts, manual checks, or assumptions drawn from a Git repository. Developed by Catalan Drupal freelancer Robert Menetray Caballero, the tool grew from years of audit scripts into the contributed Drupal Site Audit module and an optional dashboard focused on live project state, including configuration, logs, module versions, performance patterns, security-related maintenance signals, and score history across sites.

Robert has worked with Drupal since 2009 and has specialised exclusively in Drupal development since 2010, covering backend programming, custom modules, third-party integrations, frontend layout, site building, and server administration. His freelance work shaped DruScan’s direction: the module is not designed to replace expert judgement, but to help developers, agencies, project managers, NGOs, and public-sector teams identify common issues more quickly, especially when several agencies or external contributors have worked on the same project.

In this interview with Kazima Abbas, sub-editor at The DropTimes, Robert discusses DruScan’s technical model, privacy boundaries, scoring approach, and role as a Drupal-focused product built on freelance practice and open-source contributions.

TDT[1]: What first pushed you to turn your audit scripts into DruScan?

Robert Menetray: Honestly, it came from two directions at once. On one side, I'd been building little audit scripts for years. Every time a client showed up with "the site's slow" or "can you run a security audit" or "review the custom code we inherited," I'd reach for the same set of scripts to speed things up. Nothing fancy, just stuff to save me from running the same checks by hand every single time.

The other side was AI. I started leaning on it heavily for development, and what I was missing was something deterministic to verify the output was actually correct. I wanted to run a command or open a dashboard and confirm that what the agent did made sense: field configs that are set up wrong, image styles defined but never used anywhere, Twig best practices, or just the last 24 hours of logs grouped in one place.

Then, at DrupalCamp Spain 2025, I talked to people who had similar homegrown scripts. There are contrib modules covering bits of this, but nothing that pulled it all together. That conversation is what pushed me to stop treating it as personal scripts and turn it into a proper contrib module.

From that camp until early 2026, I ended up using the Audit module, still in beta, on two real projects. One was a small agency where I came in as an external consultant to review the work they were doing. The other is a big project that has been in development for over a year, with two agencies and a few external contributors involved, myself among them, where I had to analyse and review bad practices because some things were running slowly and there were errors to track down.

Since I had the module half-built anyway, I used both as a test bench. It let me produce proper analysis documents and documentation much faster, surface the positive things the module was already catching, and fix them as I went. Mostly, it sped up figuring out the real causes so that I could act on the main ones first.

I want to be clear that none of this replaces the experience of someone who actually knows Drupal performance and security. It's just one more tool to quickly and visibly spot the most common issues that tend to show up when you work across several teams or inherit a project that has been modified by people or agencies outside your control. The multi-site monitoring and the "show that the work is holding up" angle came later, once it was a module and I could see it running across my own projects.

TDT[2]: What changed between the early beta and the stable version of the Audit module and DruScan dashboard?

Robert Menetray: Honestly, the jump from beta to stable wasn't some dramatic rewrite. It was mostly time. I had more weeks to run it against real projects, both client work and a few personal ones, and that's where the rough edges showed up. The beta just needed more mileage and, above all, fewer false positives.

By the time I called it stable, I'd cleaned up the false positives that were bothering me at the start and fixed a handful of errors that were popping up. Then the early users did the part I couldn't do on my own: they hit bugs that never showed up in my projects, and I fixed those too. A few of the things they reported weren't even in the module itself; they were visual or usability issues on DruScan, the dashboard side. So part of the polish was the module, and part was just making the web interface nicer to use.

TDT[3]: You have described DruScan as a personal bet to reduce your dependence on billable freelance hours. How has building a product changed the way you think about your work?

Robert Menetray: I'll be upfront: I wouldn't call it a transition yet; it's a bet. Most of my income still comes from selling hours, and that's fine for now. DruScan is the thing I'm building on the side because I'd like to stop having 100% of what I earn tied to the hours I can physically bill in a month.

I've tried other SaaS projects before, none of them Drupal-related, and none really took off. One or two generated some recurring revenue, but it was laughable next to what I make writing code. So I'm not naive about this. The goal isn't to retire or replace my freelance income overnight; it's a tool I genuinely needed, that I keep using more, and that I think has room to be monetised.

What's changed is more in my head than in my calendar. When you sell hours, you think in tickets and deadlines. With a product, you start asking whether something is useful enough that a stranger would pay for it without me being in the room. That's a different muscle. I also looked, years ago, at the other obvious way to scale, which was building my own agency and hiring people under me, and I dropped it. I like the technical side far more than being a project manager. DruScan is my attempt to scale a little without turning into a manager or selling more of my own time.

TDT[4]: Did building DruScan change how you think about commercial product opportunities within the wider Drupal ecosystem?

Robert Menetray: It did, though maybe not in the way you'd expect. From what I've seen over the years, Drupal has always leaned toward services. You hire an agency or a freelancer to build something, give an opinion, or fix what's broken, and a lot of what reached me was performance work: caching, snowballing complexity, layers piled on layers until the site is barely maintainable. Good work, but it's billed by the hour or by the project.

What I didn't see was many product-shaped businesses aimed at this niche. Building DruScan made me realise there's room precisely because of how the ecosystem already works. Someone with a site hires a freelancer or an agency that's juggling a dozen other sites, and nobody has the budget or the time to manually re-audit every one of them every few days.

That's the gap. I'm not really aiming at the end client with a single site. It makes more sense for the rarer large organisation with many sites, a multinational running a different Drupal site per country, an NGO with several, and above all, small and large agencies managing lots of client projects, where you can set up teams with access to specific projects or give a client visibility into only their own sites. DruScan sits in the middle: not a full manual audit every few days, but enough history to see whether the scores are getting better or worse as the team ships. I'm early enough that I honestly don't know yet who my main customer will turn out to be, but the opportunity feels real because I'm leaning on the way Drupal work already happens instead of fighting it.

DruScan sits in the middle: not a full manual audit every few days, but enough history to see whether the scores are getting better or worse as the team ships.

TDT[5]: What has actual usage shown so far? Are agencies using DruScan mainly for audits, update monitoring, environment comparison, or client reporting?

Robert Menetray: What I'm seeing so far, and keeping in mind that a lot of people are still just trying the tool out, is mostly audits of existing projects. I can't really tell from my side whether those are inherited sites or the agency's own work, but the pattern is clear: they point it at a project and look at the scores.

What I'm barely seeing is the environment comparison side. Almost nobody is registering several environments for the same project to compare, say, development against staging, production, or local. That feature is there, but people aren't reaching for it yet. The typical use is one environment, check the scores, done. To me, that reads as: they're using it as an audit tool first and foremost.

TDT[6]: What does a live-site audit catch that a repository-only scan misses?

Robert Menetray: A repository tells you what the code and the exported YAML are supposed to look like, not what's actually running. The biggest blind spots are the things that change per environment. config_split and config_ignore mean development, staging, and production can legitimately have different active configuration, so scanning one branch reads a state that might not exist anywhere in production. On top of that, settings.php can override configuration at runtime or tell Drupal to ignore certain modules or values, and none of that lives in the repo.

Then there's everything that only exists in the database: whether a field is actually in use or sitting empty, how many nodes are still untranslated on a multilingual site, the warnings and errors piling up in the log, and the size of your tables. A repo-only scan can't see any of it.

There were practical reasons too. To scan a repo, I need access to it, and plenty of companies aren't comfortable handing the whole project to a third party. You're also at the mercy of how the team uses Git, and there's no standard there. I've worked with agencies that have a clean development, validation, and production flow and others that commit everything straight to main.

So I flipped it around. Instead of scripts reading YAML and custom code from a checkout, it became a module you install on the site, ideally in the client's development environment, where it can read the database and see the real state instead of guessing from the repo.

TDT[7]: Which audit checks were downgraded, reclassified, or softened after testing on real projects?

Robert Menetray: A few, yeah. The clearest one was unused image styles. Early on, if a style wasn't referenced in any view mode or View, I flagged it as an error. Then I kept hitting styles that were genuinely in use, just called from code, so the check was wrong more often than I liked. That got downgraded.

Unpaginated entity queries were another. My first instinct was to treat any query without a range as a serious performance problem, because in theory, it can return thousands of rows. But sometimes you're listing a vocabulary that will never hold more than 20 or 30 terms, and adding a range there is pointless. So it became a warning you can look at rather than a red error.

Same story with custom code that clears or invalidates the cache. In a generic context, that's a smell, but if it lives in an admin form that a human triggers by hand once in a while, it's fine. And a lot of the Twig template checks, duplicated markup or custom or incorrect theme hook suggestions, are really maintainability notices. Better to reuse components, sure, but nothing is broken.

The bigger lesson was to stop zeroing out a score just because something exists. A small landing-page site and a large, complex, multilingual one aren't comparable. Now, most of these still show up, so you keep the visibility, but they weigh on the score gently, and where it makes sense, there are checkboxes to ignore a check entirely. Pathauto aliases for users, or BigPipe Sessionless, are recommended, but plenty of projects don't need them, and calling that a critical fault helps nobody.

TDT[8]: What guided the independent submodule architecture, and how should agencies handle heavier checks such as PHPStan, PHPCS, and PHPUnit?

Robert Menetray: The architecture came straight out of the fact that no two Drupal sites are alike. There are around 24 submodules now, and a blog has nothing in common with a multilingual e-commerce site. A site with no real frontend doesn't need the Twig or responsive-image checks at all. Independent submodules let you turn on only what's relevant, which is the only way a single tool fits projects this differently. Most of them do read-only inspections and run fine anywhere, production included.

The heavy ones are the exception, and they're flagged as such: audit_phpstan, audit_phpcs, and audit_phpunit are for development or staging only. They lean on dev dependencies you won't have in vendor on production, they're hungry for CPU and RAM, and there's no reason to point them at a live site. If you want to be strict, you keep them out with config_split, but in practice, they just sit inert where they don't belong.

Where they earn their keep is local and development work, especially as a quality gate for AI-generated code. PHPStan and PHPCS turn a vague "the AI wrote something" into a concrete list of standards violations and API misuse, which you can feed straight back into an AI loop: it reads the list, fixes them, and runs the check again. That closes the feedback loop, because the model can usually fix those easy violations; it just won't bother unless something forces it to actually run the analysis. The PHPUnit submodule sits alongside that, flagging custom modules with missing or badly structured tests so you know where the coverage gaps are before you start.

And there's a human-facing report for all of it, so a project manager can log into the development server and see whether things are improving. If the connection to DruScan is on, they see the same trend on the dashboard without touching the server.

TDT[9]: How are the 0–100 scores calculated across categories, and what should users understand about errors, warnings, and notices?

Robert Menetray: The three levels are really three levels of how much something should affect your day. Notices don't count toward the score at all. There are things worth a glance, stuff that might simplify your code or help maintenance, but that I don't think should drag a number down. Warnings do count, but they're the category most likely to hold false positives, so the message is "look at this and decide if it matters for this particular project." Errors are what I consider the genuinely common, genuinely worth-fixing problems on Drupal sites.

I'll be upfront that this split is my opinion. Someone else might see one of my warnings as an error, or shrug at something I marked critical. That's exactly why a lot of it is configurable: whether a given check counts toward the score, and the thresholds for things like active module counts or database size. I've worked on a project with a 40 GB database when most sites sit under one gigabyte, so a fixed "your database is too big" rule would be useless.

The 0–100 scale itself is deliberately simple. I wanted someone non-technical, a project manager, or a frontend developer who doesn't touch the backend, to open it and read the colour: green is fine, orange is worth a look, red is something genuinely wrong. It's the Lighthouse-style circle on purpose. Each submodule is scored its own way with its own weights, since a serious Twig issue shouldn't count the same as a serious PHPCS one, and the module audit measures completely different things than the SEO one.

One thing worth being clear about: the full breakdown, the actual errors, warnings, and notices with their detail and counts, lives in the report on your own Drupal. What travels to the DruScan dashboard is just the score per category, so what you track centrally is the number and how it moves over time. The number is a summary, not the whole picture, and that trend usually tells you more than any single reading.

TDT[10]: Can you give one example of a real issue the module detected and how the score helped prioritise the fix?

Robert Menetray: I can give you a few simple ones, since they're easy to picture. There's a database audit submodule that looks at total table sizes and flags the problematic ones. It scores based on the size limits configured per table and per database, so teams can quickly see which tables are getting out of hand and decide whether to act.

Another is the Twig template audit. It catches templates that aren't bubbling cache metadata correctly, or code in templates that's just not great, the kind of thing that hurts maintainability. It's not a perfect audit, and it won't catch everything, but it surfaces a lot of things that tend to slip by, and that's worth a look.

The Views audit is another good one. Among other things, it flags Views without proper permissions. In a couple of cases, it caught Views that looked like admin Views but had no permission set, which meant data was exposed to anyone who knew the URL. It also helps get View caching right: it detects the cache tags that should be used, because Drupal will happily apply a generic node_list tag instead of the proper node_list:[bundle] tag, and on high-performance portals that means a lot of unnecessary invalidations.

There was also a case where it pointed out modules still sitting in the codebase that were actually uninstalled and unused, so we could clean those up and trim the contrib modules the project didn't need.

On prioritisation, that's really down to whoever runs the site, the agency or the freelancer. The module gives the relevant information for each audit, and it's the human who decides what's most important. The obvious move is to start with the worst scores. If a site has a 10 and a 90, it makes sense to attack the 10 first. But still, review all of it, because some things are two-minute wins and others, like refactoring code, take a lot more time and validation. Prioritising what's important and prioritising what's quick to fix are two different things, and it's up to the team to decide where to start.

The full report never leaves your server.

TDT[11]: Why was it important to keep the Audit module usable without the DruScan dashboard?

Robert Menetray: Two reasons, really. The first is just contributing back. I've been living off Drupal for 15 years, and putting something useful into the community feels right. The second is that I wanted anyone to be able to use it on any project, personal or commercial, without paying for or even touching DruScan.

The open-source part matters more than it looks. Because the code is public on Drupal.org, anyone who cares about privacy can read exactly what the module does and what it leaves on their servers. That's the deciding factor for the kind of client I have in mind. I've worked for NGOs and public administrations, and there you often can't send data outside the system at all, or you're only allowed to install contrib modules from the community rather than something pulled off a third-party site.

So the module has to stand completely on its own. You can run the audits, see the dashboard inside your own Drupal, and never enable data-sending at all. Or enable just part of it, the scores but not the module-version inventory, for instance. Tying the local auditing to my SaaS would have killed it for exactly the projects where I think it's most useful.

TDT[12]: What data stays on the local Drupal server, and what is sent to the DruScan dashboard?

Robert Menetray: It's easier to explain than people expect. The module does all the work in whatever environment it's installed in: development, staging, or production. When you open an audit page, it recalculates everything live and shows you the full detail, every error, warning, and notice with its context. But that full report never leaves your server.

If you connect to DruScan and let cron sync, what actually travels is a short, fixed list: the 0–100 score for each enabled submodule, your module list with versions, and the Drupal core version. That's it, nothing else. The scores alone are enough to build the dashboard and the history, so you can watch a number climb or drop across all your projects, and the module inventory is what powers the "which of my sites has a pending security update" view. When a security release lands, you see exactly which projects it touches instead of logging into 10 admin panels.

What never leaves the server is everything else, and I mean everything: custom code, configuration, field values, View names, the specific errors themselves, users, their names and emails, and database contents. The module can read those because any module installed on a Drupal site can, but it only ever turns them into a score. I don't receive your code or your configuration on my side, and I don't want to. It's useless to me, it costs me storage, and holding it would be a liability for data that does nothing for me. That's a deliberate choice, because I built this with NGOs and public-sector projects in mind, where data simply can't go to a third party.

TDT[13]: What steps remain before the Audit module can be covered by Drupal's security advisory policy, and what should agencies keep in mind until then?

Robert Menetray: The honest answer is that what I mostly need is time. This is a project I build in extra hours, weekends when I can free some up, that kind of thing. Right now I'm working on two things at once: adding Drupal 12 compatibility and refactoring parts of the code so I can actually request security advisory coverage.

When that's done, ideally in June 2026, and if not, sometime over the summer, I'll apply. It's one of my priorities. But I can't promise a date, because my time is limited. I've got other clients, some weekends go to family or friends, and I just do what I can. The goal is to have security coverage by the end of summer 2026, but I'm not going to oversell it.

For agencies that feel uneasy in the meantime, there are two options. One is to wait until it is covered by the community's security policy. The other is that the module is fully contrib, so all the code is right there in the open. Agencies can read through it themselves and confirm it isn't doing anything it shouldn't.

And keep in mind what the module is actually for: it surfaces things for a human to judge. It's not a certified security scanner, and I'd never sell it as one. A finding is a prompt to go look, not a verdict, and the real security call still belongs to someone who knows the project.

The biggest safeguard isn't something I promise; it's the fact that you can check.

TDT[14]: What safeguards keep future DruScan features from weakening that privacy model?

Robert Menetray: The biggest safeguard isn't something I promise; it's the fact that you can check. The module is contrib, and the code is readable by anyone. If a future version started collecting something new, it would be right there in the diff for anyone to see. Hiding data collection in an open-source module is the kind of thing that comes to light sooner or later, and it would be a stupid way to burn the trust the whole thing depends on.

Worth saying plainly: any module you install has full database access, mine included. That's how Drupal works, and people don't always realise it. So the question was never really "can it," it's "does it," and the answer stays auditable.

Beyond that, it's a design principle. I keep it deliberately simple, partly because simple is more maintainable and partly because I only want to collect the bare minimum needed to run the service. I don't store custom code or configuration on my servers today, and I've got no reason to start: it's useless to me, it costs me money, and it's a liability if anything ever goes wrong on my end. Could a future update technically collect more? Technically, sure. But it would cut against the privacy stance, against my own costs, and against the transparency that makes the project credible in the first place. The opt-in submodules help here, too, since you're the one deciding how much leaves your server, from nothing, to scores, to a full update inventory.

TDT[15]: How did you decide where the free offering should end and the paid service should begin, and what have you learned about pricing a Drupal-focused SaaS product?

Robert Menetray: The split tries to be honest about what costs me to run versus what doesn't. The module is free and open source, full stop, and the dashboard has a free tier on top of it: you can connect unlimited projects, see the current score for each one and the module list, and get a centralised view across your whole portfolio without paying anything. The free plan shows you the present. What you pay for is the past and the historical trends, so you can see whether a score is improving or sliding, email alerts when something drops or a security update lands, and environment comparison. If you only ever want a current snapshot, the free tier genuinely covers it.

What I've learned is mostly about how agencies react to paying at all. A recurring fee reads as just another cost to a lot of them, so it has to be framed as what it actually is: a reduction in the hours their people spend manually checking sites. You keep the same service, or a better one, for less effort, and then it's their call whether they drop the price to the client or keep it and pocket the margin.

I started out assuming people would prefer monthly, because the amounts are small and monthly feels lighter. It turns out that's not how companies think. What I kept hearing is that they'd rather have a single payment, or at least as few invoices as possible. This is B2B, so they're dealing with invoices, accounting, the whole thing, and a small monthly invoice is just annoying admin for everyone.

Annual made a lot more sense. The amounts are small enough that billing monthly is kind of pointless anyway. I did consider something semi-annual, but in the end I simplified it to annual, and I added a lifetime option as a discount to reward people who want to pay once and forget about it.

There's also a logic to the service itself. This isn't something you pay for one month and cancel the next. The whole point is permanent monitoring: watching how a project evolves over time and getting alerted when something new shows up. It doesn't make sense to jump in and out, or to keep switching which project you're paying for. The natural setup is to have all your projects centralised in the platform at once. That's why I set annual as the minimum. And for what it gives you, I still think it's very much worth it.

TDT[16]: Which audit submodules are suitable for production, and which should be restricted to development or staging environments?

Robert Menetray: I'd reframe "safe" a bit. It's less that some are unsafe and more that some just aren't recommended to run in full on production. The heavy ones are things like PHPStan, PHPCS, and the code complexity audit. They lean on libraries, PHPCS for example, that you don't really want sitting on a production server. Those are usually Composer dev dependencies you keep in local or development environments. And you don't want a heavy task that takes longer than the rest of the audits running on production, because it can eat into the time cron spends doing its work.

The good news is the module handles this gracefully. You can leave those submodules enabled on production, and they simply won't compute a score if the required library isn't installed, which is exactly what you'd expect.

My recommendation is one of these: either enable those submodules only in pre-production environments like local or development, or set it up in config_split so they don't end up active on production. Or, just as valid, leave them active on production but keep the dependencies out of it. If PHPStan and PHPCS are declared only as dev dependencies, when you deploy to production those libraries won't be there, the module detects they're missing, and it just skips scoring those sub-audits. This is a classic composer install --no-dev case.

TDT[17]: DruScan highlights use cases around AI-generated Drupal code and automated quality reviews. Which checks are operational today, and where does the Audit module stop?

Robert Menetray: First, a clarification, because the framing trips people up: there's no AI inside DruScan or the module. I built them with AI's help and reviewed the code myself, but what runs is deterministic. It's code looking for known patterns in your code and configuration, not your project being shipped off to some third-party model to be analysed. DruScan doesn't use AI either, partly because of cost and partly because of privacy. I'm not about to send module versions or active-module lists to an outside provider.

I learned that one the hard way. An earlier SaaS of mine was an AI wrapper, and I hadn't priced the usage properly, so the more people used it, the more it cost me. It didn't scale, and it lived or died on third-party models that kept shifting under me. I came out of that sure I don't want a business whose core is someone else's non-deterministic model that hallucinates and keeps getting more expensive.

So what's operational today is all the deterministic stuff: the performance, Twig, modules, SEO, and security checks the module already runs. Where AI comes in is on the other side, as a consumer of those checks. The PHPStan, PHPCS, and PHPUnit submodules expose their results so an AI loop can read a concrete list of violations, fix them, and run again.

As for the line, I've written about this on the blog. You can't trust AI-generated code blindly. A lot of the time it works, but it's not the best version, or it skips a best practice, and how often depends heavily on the model, a Qwen or a Kimi versus something like Opus.

My rule is simple: I read what it produces, even diagonally, decide whether it's right, tell it what to change and why, and I'm the one who makes the commit. My honest take today is that AI doesn't replace a developer. It replaces a developer with no judgement, the copy-paste-without-understanding kind. The person who reviews the output and knows why one solution beats another isn't going anywhere. The line is right there: human review, human commit. Maybe smarter models in a few months let me delegate more, but that's where I draw it now.

Honestly, judgement is needed everywhere. The module gives recommendations and visibility into things that would otherwise go unnoticed, but it's not 100% reliable, and it's definitely not something you hand to someone with zero Drupal knowledge. It might tell you, "you should install this module," but maybe in that particular case the module makes no sense, or it was deliberately dropped for a reason specific to the project. Or it tells you to change a Twig template, but that code is there on purpose and shouldn't be touched.

At the end of the day, it's a tool built for developers who know how to read it, designed to surface the problems that already exist. There's also a configuration layer that lets you ignore issues that are false positives for your project, because some configurations or bits of code can look wrong but make perfect sense in context. For example, taxonomies or users without Pathauto can be totally fine if those pages aren't accessible from outside and aliases shouldn't be generated for them. But on another project, aliases may be needed for users, taxonomies, or media. There are a lot of these case-specific details, and the module's job is to surface the common things someone would normally review to judge how well a site is configured and built.

So yes, you still need someone with experience to decide whether what the module says actually applies. That can be a senior developer, or even a junior developer who takes the reports, reviews them, and digs into whether each point makes sense for the project. The thing it isn't built for is the end client, the non-technical user. They can look at the scores and colours and get a rough sense of what's good and what's bad, but they can't judge how important any of it is for their project, because they can't tell whether a low-scoring audit matters more or less than a higher-scoring one. It's not a replacement for an expert's analysis. It's one more tool that makes that expert's work easier.

The line is right there: human review, human commit.

TDT[18]: Where do the Audit module and DruScan fit among other Drupal auditing tools, and what gap remains underserved?

Robert Menetray: They overlap, and they don't. Xray Audit leans toward entity analysis, content issues, migrations, and getting a read on how complex a project is. It's not really built to catch code-level problems. Site Audit is the closest to what I've done, but it's missing pieces I care about: performance anti-patterns in custom code, flagging non-recommended modules, and Twig issues like cache bubbling. So it's the nearest neighbour, but it isn't the same thing.

We're aiming at roughly the same people, honestly, someone with a Drupal project who wants a fast read on its state, and I'd genuinely encourage them to try mine too. My opinion is biased, I built the thing, but I think it's more complete and surfaces more of what actually matters across the common cases: a performance or security pass, a best-practices check, picking up an inherited project and seeing where it stands at a glance, or giving a non-technical person a visual sense of whether the project is getting more tangled or actually improving.

The gap, I think, is the layer on top. DruScan gives you a dashboard across many sites, updates, and security alerts, and a history of how scores move over time. There haven't really been many services doing centralised update and security alerting for Drupal in one place, and that, combined with the AI feedback loop, is where I see the room.

TDT[19]: What did the naming process teach you about branding, discoverability, and etiquette in the Drupal ecosystem?

Robert Menetray: A few things, and the order they happened in matters. My first instinct was the obvious route: Drupal Audit, Drupal Monitor, something that says exactly what it is. But you can't build a commercial product around the Drupal trademark, it's owned by the Association and they're within their rights to defend it, so anything with the full word in it was out. That's why I ended up with a name that only nods to it, "Dru" for Drupal and "Scan" for what it does.

Before I landed there, I nearly made the classic mistake. I liked the idea of a forge and bought DruForge on impulse, then did the search I should have done first and found an active project in the community with a very similar name. Using it would have created confusion with someone else's work, so I dropped it. That's the real etiquette lesson: in a community this small, you check before you plant a flag, because stepping on an existing project's name isn't a great way to introduce yourself.

The irony is that it happened to me anyway from the other side. Days before I registered DruScan, another company had spun up a repo with the same name, a tool that runs against repositories, close to what my old scripts did before this became a module. I thought hard about changing, but I had the domain and the Drupal.org namespace; they didn't, and the products are different enough in approach that I decided perfect was the enemy of done and kept it.

On discoverability, my honest view is that the name matters least. What gets you found is useful work and content people actually want to recommend. It just needs to be easy to remember and not awkward to say. The one bet I'm still unsure about is keeping DruScan completely separate from my personal freelance brand instead of hanging it off my own name.

I did it because I want it to stand on its own and not depend on me, but my personal brand is already tied into Drupal, so I may have made the reach harder on myself. Time will tell.

TDT[20]: Now that the module and dashboard are stable, what comes next for DruScan?

Robert Menetray: Right now my focus is on Drupal 12 compatibility and getting the security coverage I mentioned earlier. That's the priority, and it's the thing I'm putting my limited time into.

Beyond that, I don't have a big roadmap of major features at the moment. There are some visual and UX tweaks on the dashboard, how data is shown, how you navigate around, but that's more cosmetic than functional, so it's low priority and I'm not dedicating much time to it. Once security coverage is in, I'll see what comes in from users. If I start getting feature requests, I'll weigh them up and build accordingly. As things stand, I'm pretty happy with how the module, the dashboard, and the alerts work for keeping an eye on my clients' projects.

The one bigger thing I might tackle down the line is multilingual support. Everything is English-only right now, mostly because that was the simplest path for me to ship. It was actually designed from the start with multilingual sites in mind, but having done a fair bit of multilingual work myself, I know how much extra effort it is to run a site across several languages properly. I'd like the web interface to be available in more languages, not least because English isn't my first language, but for now I parked it for lack of time. Maybe once security coverage is sorted, I'll give it some attention, starting with Spanish, since Catalan and Spanish are my main languages. But right now, it's not a priority.

TDT[21]: What would count as genuine success for DruScan?

Robert Menetray: More people using it is the obvious one, and sure, I want that. But the version of success I actually care about is it becoming something of a standard, especially now with AI in the mix.

The risk I keep seeing is a junior who barely knows how Drupal works trusting whatever the AI tells them, configuring things wrong, and leaving a site that's unstable or quietly not doing what it should, or shipping code that isn't really up to the community's best practices. If a tool like this becomes a normal part of catching that, if people recommend it and agencies are known for building it into their workflow, that's the win in my head.

Obviously, more users on the free tier or the paid one is better for me, I'm not going to pretend otherwise. But I'd rather measure this in non-monetary terms: whether it's actually useful to the community, and whether it leads to Drupal sites that are better maintained and more up to date down the line. If that happens, I'll count it a success regardless of the numbers.

I'd rather measure this in non-monetary terms: whether it's actually useful to the community, and whether it leads to Drupal sites that are better maintained and more up to date down the line.