Not every project needs a pipeline
CI/CD has a culture of being mandatory — every README has a green badge, every tutorial assumes Actions. The truth is more nuanced. Some projects are objectively better off without it.
Cases where CI is genuine overhead
- One-shot scripts. A 50-line bash script that runs once and produces a CSV. The CI setup will outlive the script.
- Personal config dotfiles. The 'tests' would just be 'this still loads in zsh' — your shell tells you that immediately.
- Working notes / scratch repos. If the audience is one person, the feedback loop is already save and re-run.
- Throwaway prototypes. If the code's life expectancy is one week, writing CI for it is yak shaving.
- Untestable codebases (until you make them testable). CI without tests is theater. Get to one running test first, then add CI.
Signs the project graduated and now needs CI
- More than one person commits.
- You've already broken main once and it cost real time to find out.
- The code runs somewhere other than your laptop (a server, a colleague's machine, a customer's environment).
- You wrote 'I'll just remember to run the tests before pushing' and then forgot.
The principle: add CI the moment the cost of forgetting exceeds the cost of the YAML, and not before. Pippa runs CI on her own codebase. She does not run CI on a one-line bash alias.