What a Good CI/CD Pipeline Looks Like for an Early-Stage Product

A CI/CD pipeline is one of those things that's easy to defer. "We'll set up proper deployments later." "Let's just get the app working first." "We can do manual deploys for now."

We don't defer it. Every project we ship has a CI/CD pipeline from day one. Here's what we build and why.

What CI/CD Actually Means

CI stands for continuous integration. CD stands for continuous deployment. Together, they mean: every time a developer pushes code, a set of automated checks runs, and if everything passes, the code gets deployed to the live environment automatically.

No manual steps. No "I'll push it this afternoon." No "it works on my machine."

The Stack We Use

For most projects, our pipeline is built on two tools: GitHub Actions for the automation, and Vercel for hosting and deployments.

GitHub Actions runs whenever code is pushed to the repository. It's configured via a YAML file in the codebase, which means the pipeline configuration is versioned alongside the code. We can see exactly what changed, when, and why — just like the rest of the codebase.

Vercel handles the actual deployment. When GitHub Actions confirms that the code is clean, it triggers a Vercel deployment. Vercel builds the application, runs any build-time checks, and publishes it to the live URL. The whole process typically takes two to four minutes.

What the Pipeline Checks

A basic pipeline for an early-stage project does three things:

Type checking. For TypeScript projects, we run tsc --noEmit to catch type errors that might not surface until runtime. This is the cheapest form of bug prevention available.

Linting. We run ESLint to catch common code quality issues and enforce style consistency. This matters more as the team grows, but it's worth having from day one.

Build verification. We run the production build and confirm it completes without errors. This catches issues that type checking and linting miss — like a component that imports something that doesn't exist, or a build-time configuration error.

For projects with test suites, the tests run here too. For early-stage projects where tests are sparse, we at minimum ensure the build succeeds.

Preview Environments

One of the most useful features of this setup is automatic preview environments. Every pull request gets its own live URL — a fully deployed version of the application with the proposed changes applied.

This means code review includes actually using the feature, not just reading the diff. It also means non-technical stakeholders can review changes without needing to set up a development environment. They click a link and see exactly what's about to be shipped.

The On-Call Question

A pipeline that deploys automatically raises an obvious question: what happens when a bad deploy goes out?

The answer is that good monitoring catches problems quickly, and rollbacks are fast. Vercel keeps a history of every deployment and can roll back to a previous version in seconds. The goal isn't to prevent all bad deploys — it's to detect and recover from them quickly.

Why This Matters for Early-Stage Products

The argument for deferring CI/CD is usually that setup takes time you don't have. The counterargument is that manual deployments take more time over the course of a project, and they compound risk in ways that are hard to quantify until something goes wrong.

More importantly, a CI/CD pipeline changes the culture of development. When deploying is automatic and invisible, developers ship more frequently. More frequent, smaller deployments mean easier debugging, faster feedback, and lower risk per release.

The alternative — batching up changes and doing a large manual deploy periodically — creates exactly the conditions that make deployments stressful and bugs hard to trace.

Set it up on day one. It pays back within the first week.