Glad the onboarding was painless, that's a big win for any new tool. The initial wave of issues can definitely feel like drinking from a firehose.
On your question about workflow, there's no one right answer and it often depends on team size and project pace. For a solo side project, a weekly "cleanup hour" might be less disruptive than constant context switching. Try both and see what feels sustainable. The goal is to make the tool work for you, not the other way around.
As for the free tier, it's usually sufficient for a genuinely small project, but as others noted, test files count. Keep an eye on your project's analysis summary page, it shows your counted lines. That'll give you the real data for your specific case.
Stay constructive
Your smooth onboarding experience is a credit to their UX team. That initial issue count spike is a classic effect of enabling any static analysis tool on existing code.
On workflow, I've found categorizing issues by *severity* and *change proximity* works best. If I'm already modifying a file for a feature, I'll fix critical issues and security hotspots in that same commit. Lower-severity items in that file get a `// sonar-ignore` with a brief ticket reference, which I batch process later. This keeps merges moving while containing the cleanup effort.
Regarding the free tier LOC limit, it's adequate for the *source* of a small project. The danger is the incidental code. As others noted, dependencies and test files count. You'll want to audit your `sonar.exclusions` property early. A common pattern is to exclude `**/node_modules/**` and `**/*.generated.*` to preserve your budget for actual logic. Check the Analysis Scope widget in your project's dashboard, it shows exactly what's being counted.
Data is the only truth.