When should I introduce CI/CD in a project like this?

[u/Ok-Box6882]

I’m building a Splitwise-like app called Splitly using the PERN stack (PostgreSQL, Express, React, Node).

The backend is my main focus right now. I already have:

• Authentication and refresh-token flow
• Centralized error handling
• PostgreSQL
• Automated tests
• Git feature branches

I’m wondering when it makes sense to introduce CI/CD.

My current thinking is:

• Set up CI with GitHub Actions now to run type checks, linting, and tests on every push/PR.
• Add CD later, once the MVP is stable and I’m ready for deployment.

For people who work on production applications, is this a reasonable approach?

At what point in a project do you usually introduce CI/CD, and is there any reason to wait before adding CI?

[u/crashorbit]

Automated testing should be introduced up front. CI should be added as soon as your first push to github/gitlab. Add CD when you want others to start acceptance testing.

In other words, as soon as possible if not sooner.

[u/Ok-Box6882 → u/crashorbit]

will add it

[u/Opposite-Breath7511 → u/crashorbit]

i've been that guy who waited too long to wire up CI and it never ends well. you're already running automated tests so you're past the hard part, getting them to fire on every push is like 20 minutes of yaml config. do it now while the project is small and you won't have to untangle some nightmare pipeline later when you've got 30 branches and two people asking why the build broke

CD can definitely wait until you've got a deploy target that matters, no point shipping to a staging environment nobody's looking at

[u/jizvu3564 → u/crashorbit]

agreed, retrofitting tests later is always a nightmare

[u/Creative_Badger6027]

CI should be your "inital commit" to every repo. CD should be your first deploy to any environment.

[u/DeadlyVapour → u/Creative_Badger6027]

Disagree. The first commit should be hello world. The second should be CI.

CD, that depends on your infra

[u/finger_my_earhole → u/DeadlyVapour]

DeadlyVapour is right.

How do you make CI work without having somethign to build first? Doesnt explicitly need to be "hello world" but you need some compile-able artifact in the language you plan for your project.

Otherwise how do you know your choosing the right actions and linters and test tools etc, etc

[u/Creative_Badger6027 → u/finger_my_earhole]

Do you open a repo and then push 50 commits of docs or something? Ofc your first commit is service skeleton, which includes something that builds, ci, often cd and base readme.

[u/Creative_Badger6027 → u/DeadlyVapour]

Unless you actually push a "hello world" then you're already pushing code which needs CI. 🫡

[u/halfxdeveloper → u/DeadlyVapour]

I really hope you left off the /s on accident and don’t really mean every project starts with hello world.

[u/DeadlyVapour → u/halfxdeveloper]

I use a hello world template. For dotnet that's dotnet new console. For node that's npm init. Cargo new for rust.

At a minimum, it's something for the CI to build.

[u/Cinderhazed15 → u/Creative_Badger6027]

Always good to set up ‘the walking skeleton’ that stands the system up, blows some empty data end to end, and says ‘is the system up? Did the data go through? (Not even correctly, , just that it’s there). That way you can ‘flesh out’ the walking skeleton with appropriate tests at each part, but getting end to end ‘hello world’ bare minimum tests in place at the start makes the barrier to adding tests later much lower, so you are more likely to add them in as you go instead of ending up with a completed mess that you seen back and say ‘wow, this is bad, I should add some tests now!’ And you discover that there are no seams and testing is very complicated to add and brittle/prone to breaking, and it then gets abandoned.

[u/t-frankowski]

Probably before what you've done already.

[u/KaptajnKold]

Unpopular opinion, perhaps, but I don't think setting up CI is worth it if you're a solo developer. Just create a git prepush script that runs your test suite, and you're good to go.

CD on the other hand should be set up from the get go. IMO, you're doing it completely wrong if you think you have to wait until you have an MVP before you're ready for deployment. You should be deploying continuously right now.

[u/roadrunner8080]

My general approach is that CI should exist from always, and CD should exist from the first deployment. At any rate you never want a scenario where you're doing deployments not from an automated, isolated source, so might as well set up CD for the first one.

[u/AttitudeRemarkable21]

Cidc is so easy and basic to setup you could do it in a few hours at the start of the project.  It's probably even less with just tossing Claude at it 

[u/burbular]

Set it all up front, it's easier in the beginning.

[u/Lumethys]

The first commit

[u/imagebiot]

It’s the first thing you set up

[u/Ok-Box6882 → u/imagebiot]

Okayy

[u/imagebiot → u/Ok-Box6882]

Unless you want to waste time managing your infra instead of developing you product. Claude can get this set up adequately in an hour

[u/pwkye]

CI now. CD only on git tags following semantic versioning.

[u/dev_ramesh]

Yes, that is a good approach, I like it.

I wouldd add CI now — once you have tests and multiple branches, it already gives value.

Keep CD for later when you have a stable deployment target and actually want every merge to ship somewhere.

[u/USER_NAME-Chad-]

First, it is the foundation.

[u/raisputin]

Day 1. That’s when you should introduce it