You don't need a paid consultant or an enterprise contract to get a real picture of your codebase's health. Most of the tooling that professional reviewers use has a free tier or an open source equivalent that will catch the majority of what matters. Here's a working list, organized by what each one actually checks.
None of these are exotic recommendations. What matters is running them consistently rather than once, and actually reading the output instead of letting it pile up in a dashboard nobody opens.
Vulnerability scanning
Snyk has a generous free tier for open source projects and integrates directly with most CI pipelines, flagging known vulnerabilities in your dependency tree as part of your normal build process rather than as a separate step someone has to remember to run.
The National Vulnerability Database itself is free to query directly if you want to check specific packages by hand, and it's the same underlying data most commercial scanners are built on top of.
Photo by Massimo Botturi on Unsplash
Whichever scanner you use, set it up to run on every pull request rather than as a one-off scan you remember to trigger manually. A vulnerability caught before a merge is a five minute fix. The same vulnerability discovered six months later, after three other systems have started depending on the vulnerable version, is a much bigger project.
Code quality and maintainability
SonarSource offers a free community edition of SonarQube that flags code smells, duplicated logic, and complexity hotspots, the parts of a codebase that tend to accumulate bugs and slow down onboarding for new engineers. It's not glamorous, but the trend line over time (is complexity going up or down) is often more useful than any single snapshot.
CodeClimate offers a similar free tier for open source repositories and pairs well with SonarQube if you want a second opinion on the same codebase.
Run either tool once, ignore the overwhelming initial count of findings, and instead watch the number over the following months. A codebase that's actively maintained should see that number hold steady or trend down. One that's climbing steadily is accumulating debt faster than anyone's paying it back, which is worth knowing regardless of whether a review is on the horizon.
License compliance
FOSSA has a free tier that scans your dependency tree for license conflicts, which matters more than most teams assume until an acquirer's legal team asks about it directly. The Open Source Initiative is the best free reference for understanding what different license categories actually obligate you to do, useful to have open alongside any automated scan.
Most permissive licenses, MIT, Apache 2.0, BSD variants, carry no meaningful obligations beyond attribution. The ones worth flagging are copyleft licenses that can require you to open source code that links against them, which matters a great deal if your product is closed source and matters far less if it already is not.
Test coverage visibility
Codecov has a free tier for open source and reasonably priced private repo plans, and it turns "we have tests" into an actual number you can track over time, broken down by which parts of the codebase are thin. Pair it with whatever test runner your stack already uses, Jest covers most JavaScript projects out of the box with coverage reporting built in.
The number by itself is less useful than the breakdown. A codebase sitting at seventy percent overall coverage could mean even coverage across every module, or it could mean the payments module sits at twenty percent while a rarely touched admin panel sits at ninety-five. Only the breakdown tells you which one you're actually looking at, and only one of those scenarios should worry you.
Observability and incident history
You can't audit incident response without data, and Sentry has a free tier that captures errors in production with enough context to reconstruct what happened after the fact, which becomes your incident history whether or not you're formally tracking it elsewhere. Datadog offers a limited free tier as well if you want broader infrastructure visibility alongside application errors.
Neither tool replaces the human step of actually writing a postmortem after something breaks, but both make that step faster, since the timeline and root cause are partly reconstructed for you instead of pieced together from memory and scattered Slack messages days later.
Dependency freshness
GitHub's built-in Dependabot, available on every repository hosted on GitHub, will open pull requests automatically when a dependency has a newer version available, which is the fastest way to see how far behind your stack has drifted without running a manual audit.
Even if you don't merge every update immediately, having Dependabot enabled turns "how out of date are we" from a guessing game into a visible, ongoing list. Teams that let it run unattended for a year and then try to catch up all at once usually find the backlog has grown into dozens of interconnected breaking changes instead of a steady trickle of small ones.
Documentation and knowledge mapping
Tools built for engineering docs, like Notion, don't audit anything automatically, but they're worth including here because a documentation gap is itself a finding worth surfacing. If your team doesn't have a shared place for architecture notes and runbooks, that absence is as informative as any scanner output, and it's free to fix starting today.
A lightweight exercise that pairs well with any of the tools above: for each major system, note who on the team could debug a production issue in it without paging the original author. Systems with only one name on that list are worth flagging for documentation investment regardless of what the automated scans report.
License scanning is worth a second pass
It bears repeating separately from the earlier mention: license issues are the finding teams are least prepared for, precisely because they don't show up as an error or a crash. Nothing breaks when a dependency's license terms don't match how you're using it. The problem only surfaces when someone with a legal background reads the terms closely, usually much later than anyone would like.
Run FOSSA or a similar scanner even if your product feels far removed from anything license-sensitive. Teams building on open source stacks accumulate these dependencies faster than anyone tracks manually, and a copyleft license buried three layers deep in a dependency tree is exactly the kind of thing that gets missed without a dedicated tool checking for it.
Putting it together
None of these tools require a procurement process or a sales call to start using. Run the free tiers on your main repository this week, write down what each one flags, and you'll have a rough version of the same picture an outside reviewer would build, before anyone asks you for it.
Treat the first pass as a baseline rather than a pass or fail result. The value compounds when you rerun the same tools quarterly and compare against the previous baseline, since a team that's actively closing gaps looks very different from one that ran the scan once and never opened the report again.
For the fuller picture of what a technical review actually checks beyond tooling output, including documentation, incident history, and data pipeline reliability, this guide on preparing for technical due diligence walks through the rest. 137Foundry works with teams on exactly this kind of preparation when the stakes are higher than a routine cleanup.
Top comments (0)