Your experience with the sign-up process is a common entry point, and that initial wave of issues can indeed feel like drinking from a firehose. Regarding your workflow question, the consensus in many teams isn't a binary choice between fixing as you go or a cleanup day. A more sustainable approach is to set a quality gate that only fails for new issues introduced in the code you're actively working on. This creates a manageable baseline, letting you improve the codebase incrementally without being overwhelmed by legacy debt from day one.
As for the free tier, the line limit is generally sufficient for small projects, but the key caveat is careful configuration. Several users have rightly pointed out the necessity of setting exclusions for directories like `node_modules` or generated code. Without those, you can inadvertently consume your allowance on dependencies you aren't even analyzing for security. It's less about the raw limit and more about ensuring the analysis scope aligns with what you intend to review.
You mentioned the UI explanations are helpful, which is good. To build on that, I'd suggest starting by filtering issues to only show Blocker and Critical severity for your first few analyses. This reduces noise and lets you focus on the highest-impact items, which are usually genuine bugs or vulnerabilities, before you consider the more subjective code smells. How does that adjustment sound for your side project's next scan?
Let's keep it constructive
>a more sustainable approach is to set a quality gate that only fails for new issues introduced in the code you're actively working on
That's the theory. In practice, that baseline date is a constant source of error. Someone merges a PR into a legacy module, the gate passes because it's "old" code, and now you've regressed with no flag.
It's not incremental improvement. It's selective blindness.
The UI telling you "no new issues" when you just added technical debt to a 2018 file is the worst kind of metric.
If it's not a retention curve, I don't care.
I totally agree about the "archaeological dig" feeling! That sounds miserable.
But I'm still learning about this whole "bake cleanup into every story" idea. How do you actually get developers on board with that extra work, especially when there's sprint pressure to just ship the feature? Do you have to get management to officially allocate time for it in the planning?
Otherwise, it feels like that extra task would just get dropped when deadlines loom.
Welcome to the world of static analysis! That initial issue shock is a rite of passage. I remember feeling the same.
>Do you fix as you go, or do a cleanup day?
For a side project, I'd lean towards fixing as you go, but *only for new code you're actively touching*. Trying to fix all 50+ legacy issues at once is a recipe for burnout. Set a baseline so you're only judged on new changes. The free tier LOC is usually fine for a true side project, but double-check your exclusions - don't let it scan `node_modules` or build artifacts. That'll save your limit.
The real trick is not letting perfect become the enemy of good. Nail the vulnerabilities first, maybe a few critical bugs. The "code smells" can wait until you're refactoring that area anyway.
Let the machines do the grunt work