A solo developer or two person startup needs three things: a dependency and code scan on every pull request, a weekly rescan of what is already shipped, and an editor extension for fast hints. Add heavier tooling only when a customer, a regulation, or a real incident asks for it.
Why less is right at this size
With one or two engineers, the scarce resource is attention. A tool that produces a hundred findings you cannot triage is worse than a smaller one that produces five you will fix. The goal is not coverage on paper. It is a loop that actually runs and that you actually read.
You also have no reviewer. In a larger team, a second person catches things. When you are alone, the automated check is the second pair of eyes, so it matters that it runs on every change, even your own.
The three pieces
- Pull request scan. Open a pull request even for your own changes, so the check has a place to run. Block only on new critical findings.
- Weekly rescan. Advisories appear after you ship. A weekly job tells you when old code has become risky, and costs nothing when it finds nothing.
- Editor extension. It catches issues while you are still in the file, which is the cheapest moment to fix them.
Everything else can wait: a pre-commit hook is optional, and a central policy engine is overkill.
What to skip for now
| Skip | Reason |
|---|---|
| Elaborate approval workflows | There is nobody to approve |
| Daily rescans with paging | You cannot respond that fast, and alert fatigue sets in |
| Scanning every branch and tag | Scan the default branch and pull requests |
| Custom rule writing | Defaults first, tune after you see real noise |
Make it count when a customer asks
Early customers will ask how you handle vulnerabilities. A short, honest answer helps: you scan every pull request, you rescan weekly, and you fix critical issues first. Keep the scan output and a dated note of fixes. That is evidence you can share, and it grows as you do. Do not claim any certification or attestation you have not completed.
A one hour setup
- Pick a scanner that covers dependencies and code in your languages.
- Add it to CI on pull requests, with a stable job name.
- Add a scheduled workflow for the weekly run.
- Install the editor extension.
- Create a calendar reminder for a short weekly review.
- Write a three line exception rule: who may waive, for how long, and where it is recorded. Even if it is you, write it down.
When to level up
Move to the next tier when the second engineer joins, when a customer sends a security questionnaire, or when you run more than a handful of repositories. At that point, see what a team of 20 to 50 engineers should scan.
Where Safeguard fits
You can try a scan without any setup at https://gold.safeguard.sh/scan. Safeguard also offers VS Code and JetBrains extensions, a CLI, and pull request gates, so the same tool can grow with you.
Quick check
Do I need a pre-commit hook?
Not at first. A pull request scan and an editor extension cover most of the value. Add hooks later if the team agrees on fast checks.
Is scanning only the default branch enough?
For a tiny team, scan pull requests and the default branch. Extra branches add noise without much benefit.
Last reviewed: 19 October 2026.
