CI/CD for startups: ship faster without breaking things

The startups that ship weekly outperform the ones that ship monthly. CI/CD is how you ship weekly without deploying bugs. It's the difference between a team that moves fast with confidence and a team that moves fast and breaks production every other Friday.

If you're running a startup with 2-10 engineers and you're still deploying by SSH-ing into a server or clicking "merge" and praying, this guide walks you through the minimum CI/CD setup you need. It takes one afternoon to configure, costs $0/month on free tiers, and pays for itself the first time it catches a bug before your users do.

What CI/CD means in plain English

Continuous Integration (CI) means every code change gets tested automatically. When a developer opens a pull request, a server runs your linter, type checker, and test suite against the new code. If anything fails, the PR gets a red X and nobody merges it until the issue is fixed.

Continuous Deployment (CD) means every passing test gets deployed automatically. When code merges into your main branch, the system builds it, pushes it to staging, and makes it available for review. Production deployments happen with a single click or, if you trust your test suite, automatically.

That's it. CI catches bugs before they reach your main branch. CD pushes verified code to your users without manual intervention. Together, they replace the "it works on my machine" conversation with "it passed the pipeline."

Why startups skip it (and why that costs them later)

Manual deploys work at 2 engineers. One person writes the code, the other reviews it, someone runs git pull on the server, and the feature is live. It feels fast because the feedback loop is short.

They break at 5. With five engineers pushing code, you get merge conflicts, untested interactions between features, and deploys that happen at random times. Someone merges while someone else is mid-deploy. The server has uncommitted changes from a hotfix last Tuesday. Nobody's sure which version is running in production.

By the time you have 10 engineers, manual deploys cause 2-3 production incidents per month. Each incident costs 2-4 hours of engineering time to diagnose and fix. That's 4-12 hours of senior engineering time lost every month; time you're paying for in salary but getting zero product value from.

The math is straightforward. A senior engineer costs $75-$150/hour. Twelve hours of incident response per month costs $900-$1,800. Setting up CI/CD takes one afternoon and costs $0/month on free tiers. You recoup the setup time in your first month.

The minimum viable CI/CD pipeline

You don't need a 45-minute pipeline with 200 steps. You need five checks that catch 90% of bugs before they reach production.

1. Lint on every PR

Linting catches style issues, unused variables, and common mistakes. ESLint with a standard config (like the Airbnb or Next.js preset) takes 5-15 seconds to run and catches problems that would otherwise show up in code review. This frees your reviewers to focus on logic and architecture instead of formatting arguments.

2. Type check on every PR

If you're using TypeScript (and you should be), run tsc --noEmit on every pull request. This catches type errors that your editor might miss; especially errors in files you didn't directly change but that depend on the code you modified. A type error caught in CI costs 2 minutes to fix. The same error caught in production costs 2 hours.

3. Run tests on every PR

Automated tests verify that your code does what it's supposed to do. A well-scoped test suite runs in 30-90 seconds and catches logic bugs that linting and type checking miss. You don't need 100% coverage. You need tests on the code paths that handle money, user data, and core business rules.

4. Auto-deploy to staging on merge to main

When a PR passes all checks and gets merged, the pipeline builds the app and deploys it to a staging environment. This gives your team a live URL where product managers, designers, and clients can review changes before they hit production. No more "can you deploy to staging so I can test this?" messages in Slack.

5. One-click deploy to production

Production deploys should require a single deliberate action: clicking a button, running a command, or merging to a production branch. The key word is deliberate. You want a human deciding "yes, this is ready for users," but you don't want that human running 15 manual steps to make it happen.

Tools and costs

You don't need to spend money to get a working CI/CD pipeline. Every tool in this list has a free tier that covers early-stage startups.

GitHub Actions is free for public repositories and includes 2,000 minutes per month for private repos. That's enough for a team of 5-8 engineers pushing 20-30 PRs per week. Your lint, type check, and test steps run as a workflow triggered on every pull request.

Vercel auto-deploys on every push, gives you preview URLs for every PR, and handles staging and production environments out of the box. The free tier covers most startups until they hit significant traffic. If you're building with Next.js, Astro, or any frontend framework, Vercel is the fastest path to CD.

Railway handles backend services, databases, and background workers with automatic deploys from GitHub. Pricing starts at $5/month with usage-based billing after that. It's a strong option for full-stack apps that need more than static hosting.

Fly.io deploys Docker containers to servers close to your users. It's a good fit for APIs and services that need low latency across regions. The free tier includes 3 shared VMs and 160GB of outbound transfer.

What to test and what to skip

Testing everything makes your pipeline slow. Testing nothing gives you no safety net. The right answer sits in the middle.

Test your business logic. If your app calculates pricing, validates user input, processes payments, or applies discount rules, write tests for those functions. These are the code paths where bugs cost money.

Test your API endpoints. Send a request, check the response status and body. This catches routing errors, middleware bugs, and serialization issues that unit tests miss.

Skip UI pixel testing. Don't test whether a button is 16 pixels from the top of its container. Those tests break every time you change your layout and catch zero real bugs.

Skip framework internals. Don't test whether React re-renders when state changes. The React team already tested that. Test what your code does with the rendered output.

The deployment confidence ladder

Each step in your pipeline adds a layer of confidence that the code is safe to deploy. Think of it as a ladder where each rung catches a different category of bug.

Lint catches formatting issues and common mistakes. Type checking catches mismatched data shapes and null reference errors. Unit tests catch broken business logic. Integration tests catch broken interactions between components and services. Staging preview catches visual regressions and UX issues that automated tests miss. Production is the final step, where real users interact with verified code.

Most startups need the first five rungs. You can skip integration tests early on and add them when your system grows complex enough to justify them. But lint, types, unit tests, and staging previews are non-negotiable from day one.

Preview deployments change how teams review code

Every PR gets a live URL. Not a screenshot in a Slack thread. Not a screen recording. A live, interactive version of your app with the proposed changes running on a real server.

Product managers click through the feature and leave comments on the PR. Designers check spacing and typography on their own screen. Clients see progress in real time without waiting for a demo call. This shortens feedback cycles from days to hours.

Vercel and Netlify do this out of the box. Every push to a PR branch generates a unique preview URL that updates automatically when you push new commits. No configuration needed beyond connecting your GitHub repo.

At Savi, preview deploys have eliminated the "it looked different on my machine" conversation. Stakeholders review features in the same environment where the code will eventually run. If it works on the preview URL, it works in production.

Common mistakes that slow teams down

Testing everything. A 25-minute pipeline kills developer velocity. Engineers avoid opening PRs because the feedback loop is too slow. Keep your pipeline under 3 minutes for lint, types, and unit tests. If it takes longer, you're testing too much or your tests are poorly scoped.

Testing nothing. No tests means no safety net. You'll ship bugs faster, sure, but you'll also spend your mornings fixing what you shipped the night before. Start with 10-20 tests covering your core business logic and grow from there.

No staging environment. Deploying directly from a PR to production means every merge is a gamble. Staging gives you one last chance to catch issues in an environment that mirrors production. The cost is $0 on Vercel's free tier and $5-$20/month on Railway.

Deploying Friday at 5pm. This is a cultural problem, not a technical one. If something breaks, nobody's around to fix it. Your users spend the weekend with a broken product, and your team spends Monday morning in damage control. Set a team rule: no production deploys after 3pm on Fridays. Better yet, no production deploys on Fridays at all.

How Savi sets up every project

We configure CI/CD as part of every build, not as an afterthought. Here's what every Savi project ships with on day one.

GitHub Actions for CI. Every PR triggers a workflow that runs ESLint, TypeScript type checking, and the test suite. If any step fails, the PR can't be merged. Branch protection rules enforce this so no one bypasses the pipeline, not even the project lead.

Vercel or Railway for CD. Frontend apps deploy to Vercel with automatic preview URLs on every PR and production deploys on merge to main. Backend services deploy to Railway with the same trigger pattern. Both platforms handle rollbacks if a deployment fails health checks.

Preview deploys on every PR. Clients and stakeholders get a live URL for every feature branch. They review in the browser, leave feedback on the PR, and approve before code reaches production. This replaces demo calls and screen recordings with direct interaction.

Automated type checking and linting. We run strict TypeScript with no implicit any and ESLint with rules tuned to catch real bugs, not style preferences. These checks add 15-30 seconds to the pipeline and catch 60-70% of issues before a human reviewer even looks at the code.

This setup takes one afternoon to configure at the start of a project. It runs automatically for the entire lifetime of the product. The ROI is measured in bugs that never reach production, deploys that never go wrong, and engineering hours that go toward features instead of firefighting.

Frequently asked questions