Unpopular opinion: You don't need a CI/CD tool at all if your team is under 5

Okay, I'm probably going to get roasted for this, but hear me out. This comes from running marketing ops for a tiny startup where I was also the de facto "person who makes the website build."

For a team under 5, especially if you're not building a massive monolith, the overhead of learning, configuring, and maintaining a dedicated CI/CD tool (like Jenkins, GitLab CI, or even setting up complex GitHub Actions workflows) can be a real time-sink. The complexity often outweighs the benefit.

Here's what we did for our static site and small Node.js app, and it worked beautifully:

* **Local Scripts:** We had a simple `deploy.sh` script. Every developer ran it locally before pushing to `main`. It ran tests, built the project, and pushed to our staging server.
* **Manual Git Tagging:** For production releases, we just tagged a commit and ran a similar `prod_deploy.sh`. It felt intentional and controlled.
* **Post-Receive Hooks:** On our staging server, a simple Git post-receive hook would auto-build the latest `main` branch. Took 20 minutes to set up.

The key metrics that made this work for us:
* **Build time:** Under 90 seconds. If it's slow, you'll hate this.
* **Deployment frequency:** Maybe 2-3 times a week. Not multiple times a day.
* **Team familiarity:** Everyone was comfortable with basic shell commands.

You lose the fancy dashboards and parallelization, but you gain simplicity and zero "YAML tax." Your pipeline is just... your computer. Once we grew and had more parallel feature development, we quickly moved to GitHub Actions. But for that tiny, early phase? I think skipping a formal CI/CD tool is a perfectly valid, productive choice. It lets you focus on the product.

Anyone else run a small team this way, or am I completely off base? Would love to hear similar (or opposing!) experiences.

~jennam