Most Claude Code advice assumes a team is somewhere in the loop — a reviewer, a second opinion, someone else who'd notice if something looked wrong. Working solo removes that safety net entirely, which changes what actually matters in the workflow.
On a team, a pull request gets a second pair of eyes before it ships. Solo, that check either happens — you actually reading the diff before accepting it — or it doesn't happen at all. The habit worth building deliberately: treat every accepted change as if someone else were about to merge it, because in a very real sense, you're the only one who will.
Claude Code reads project-level context files if you keep one — conventions, architecture decisions, anything a new teammate would need explained. Solo, there's no teammate to explain it to out loud, which means that knowledge either lives in a real file or it lives only in your head, re-explained every session. Writing it down once does the same job a team's onboarding doc would.
A real test suite is what lets Claude Code verify its own work without anyone else around to catch a regression. This matters more solo, not less — on a team, a reviewer might catch what a missing test wouldn't. Solo, a missing test is a genuinely missing check, not a redundant one.
It's tempting to work straight on main when there's no one else's work to collide with. A separate branch for anything non-trivial still buys a real rollback point if a multi-step change goes sideways halfway through — the benefit doesn't depend on having teammates, it depends on wanting an easy way back to where you started.
You do, every time — reading the actual diff before accepting it is the review step a team would otherwise provide. Skipping it because no one else is watching is exactly how a solo project accumulates unreviewed changes.
It's more forgiving solo than on a team, but a separate branch for anything non-trivial still gives you a real rollback point — committing straight to main removes that safety net for no real benefit.
A single real file (commonly named CLAUDE.md or similar) describing your project's conventions, architecture decisions, and any non-obvious constraints does the same job a team's shared docs would — it gives Claude Code the same context a new teammate would need.
Especially as a solo developer — tests are what let Claude Code verify its own work without a second person around to catch a regression. Without them, the review burden falls entirely on manual reading of every change.