It's worth saying plainly: a lot of software genuinely doesn't need full-tier rigor, ever. A browser extension, a CLI utility, a small personal tool — these can live their entire useful life in light tier, and that's not the workflow underperforming, it's the workflow correctly recognizing that the risk profile never justifies more.
What light tier alone still buys a small project
Even a tiny utility benefits from the parts of light tier that don't scale with project size: a tier decision that confirms (rather than assumes) the work stays small, a focused verification script instead of no testing at all, and — maybe most usefully for a side project you pick back up sporadically — an implementation_plan.md per change that tells future-you exactly what you were doing and why, the next time you open the repo after four months away.
Investigation still matters, maybe more
Small projects are disproportionately maintained by one person with limited time, which makes a guessed fix that doesn't actually work an expensive mistake — you don't have a team to catch it, and you might not touch this codebase again for weeks. The Investigate skill's insistence on a cited, verified cause is arguably more valuable here than on a heavily-staffed project, precisely because there's no safety net if the fix is wrong.
The one-folder-one-topic habit prevents the classic side-project rot
Side projects and small utilities have a very specific failure mode: an ever-growing, unstructured pile of "misc fixes" and half-remembered intentions, because there was never enough perceived stakes to justify organizing it properly. The one-folder-one-topic discipline costs almost nothing to apply even at this scale, and it's exactly what keeps a two-year-old side project's spec history legible instead of becoming exactly the kind of junk drawer bigger, better-resourced projects also fall into.
When (if ever) a small utility crosses into full tier
Rarely, but not never: if a personal tool grows a genuine new subsystem — you're adding real user accounts and a database where there was none, say — that specific change deserves the heavier treatment even if everything before and after it stays light. The tier decision is per-change, not per-project; a small utility can have exactly one full-tier moment in its whole lifetime and be light tier everywhere else.
Small projects aren't exempt from discipline — they just rarely need much of it. SpecDevShip's tier system means you get to keep it that way without having to decide to skip the process; the process decides that for you, correctly, most of the time.