I ordinarily will not even start a project until I've laid out at least a basic CICD pipeline for it. That is, in my opinion, the first and most important part of any project and I'm going to attempt to justify why. This is why you should "Set up CI/CD from day zero, THEN start the project"

If you want to be considered a software engineer rather than a develper, one of the first things you'll need is to introduce repeatable, auditable testing and a rigorous process for your work.

The pipeline is this. Artifacts are tagged with exact commit hashes. Builds run in identical, version-controlled environments (pipeline containers). You can reproduce any deployment from years ago with 100% fidelity (assuming it didn't pull in any external packages that weren't also version tagged)

You can add as additional steps to the pipeline: chaos engineering, formal verification gates, static analysis, and so on. All manner of strictness can be enforced so that no code can get past the checks.

By taking away the testing, linting, quality gates, and deployment steps from developers manual plates you've by default abstracted their jobs to now just the raw development process. They can focus entirely on code and features while the pipeline handles all these other things on their behalf.

You don't want your developers wasting brain cycles on anything you can automate. Those are expensive cycles!

it is known that the single largest source of all errors and issues in software today is human error, especially on changes, testing, and deployments.

The pipeline eliminates those errors almost entirely by enforcing that testing and deployments are fully automated. Why wouldn't you want to eliminate the largest known class of errors as your first step?

The pipeline is where you put your mandatory quality gates. It is the rigorous systematic sequence of tests and linting checks that you regulate youself with. Without this, you need to rely on fighting and discipline to maintain standards. The pipeline enforces the rigorous standards for you, so that commits can't enter the main branch until they adhere to the codified standards.

With the pipeline in place you immediately have a definition of what it means for a feature or commit to be done. That is, it passes all stages of the pipeline and makes it into main.

With a pipeline in place you never again start to accumulate untested or unintegrated changes. Every change in main has passed the quality gates and tests, or it wouldn't have made it.

In order for the pipeline to be fast and stable, you naturally choose designs that are repeatable, fast, and simple, as the irritation of waiting on a slow pipeline inherently makes it undesirable for you to build a slow or failure-prone system.

You don't need to wait for your seniors to be free to do reviews. Every commit has an inherent automated review process built right in, and so you've lightened the review load to only the high-level code review. Actual linting and testing and so on is all abstracted away by the machine.

Retrofitting a pipeline onto a project is exponentially harder than incrementally building it up from day zero. Given the importance of CICD, all projects will eventually have one, and so it makes sense to implement at the earliest possible stage, when it's easiest to do.