T

What DevOps actually means

Not long ago, software companies had two separate teams: developers who wrote code, and operations teams who ran the servers. Developers threw code over the wall; operations deployed it, kept it running, and dealt with the fallout when it broke. The two teams had different incentives and different information, which predictably led to friction, slow releases, and incidents that took too long to resolve.

DevOps collapsed that boundary. The idea is that the people who write code should also be responsible for running it in production. Not always literally — you're not expecting your senior backend engineer to be on call every night — but the mindset shifts. Engineers think about how their code behaves under load, how it fails, how it's monitored. They own the full lifecycle, not just the writing part.

In practice, for most startups, "doing DevOps" means having automated processes that test, build, and deploy code — so that deploying isn't a manual, nerve-wracking event that requires the right person in the right mood at the right time.

What CI/CD actually does

CI stands for Continuous Integration. CD stands for Continuous Delivery (or Deployment, depending on who you ask).

Continuous Integration means that every time a developer pushes code, an automated process runs — checks formatting, runs the test suite, flags anything broken. The point is to catch problems early, before bad code accumulates on top of more bad code. Without CI, developers merge their work infrequently, and merging becomes its own painful project.

Continuous Delivery means that once the code passes those automated checks, it can be deployed to production with minimal manual steps. "Can be" is important here — some teams still require a human to approve the final push to production. Others automate the whole thing, so a merge to the main branch triggers a deployment. That's Continuous Deployment, and it requires serious confidence in your test coverage.

The practical outcome: instead of deploying once a month in a high-stakes ceremony, teams that have working CI/CD can ship multiple times a day. Each deployment is smaller, less risky, and easier to roll back if something goes wrong.

If your team is doing manual deployments — SSHing into a server, pulling code, restarting a process — you don't have CI/CD. You have a process that scales exactly to the number of hours your most careful engineer can stay focused on a Friday afternoon.

What containers are and why everyone uses them

The classic deployment problem: the code works on the developer's laptop and breaks on the server. Different operating system versions, different library versions, different environment variables. Tracking down why something works in one place and not another is one of the most demoralising debugging tasks in software.

solve this by packaging your application together with everything it needs to run — the runtime, the libraries, the configuration — into a single portable unit. The most common tool for this is Docker.

Think of it like this: instead of giving someone a recipe and trusting they have the right ingredients, you hand them a sealed meal kit. The environment is consistent regardless of where the container runs. Your developer's laptop, the test environment, the production server — the container behaves the same in all three.

This is why "it works on my machine" has become a running joke rather than a regular blocker. Containers mostly killed that problem.

The follow-on technology — Kubernetes — manages containers at scale, handling things like running multiple copies of your service, restarting them if they crash, and routing traffic between them. Most early-stage startups don't need to run Kubernetes themselves; managed services like AWS ECS or Google Cloud Run handle the container orchestration so your team can focus on the application.

The part most founders get wrong

CI/CD is not the same as fast, safe deployments. It's the infrastructure for them. The difference matters.

A team can have a fully automated pipeline that deploys broken code to production five times a day. If there are no meaningful tests, CI just means "we automatically ship whatever we wrote." The automation amplifies whatever discipline — or lack of it — already exists in the codebase.

The question to ask your team isn't "do we have CI/CD?" It's "what does our pipeline actually check before it deploys?" If the answer is "it runs the tests," ask what percentage of the codebase those tests cover and when they were last updated. If the answer is "it just builds the Docker image and pushes it," you have deployment automation but not quality gates.

This matters for founders because the sales pitch around DevOps is usually framed as speed. And yes, good CI/CD makes teams faster. But the less-discussed benefit is safety — the ability to catch regressions before users do, roll back a bad release in minutes, and deploy on a Friday without everyone dreading Monday morning.

Speed without safety is just faster failure.

What this looks like when it's working

One of the better-documented examples of CI/CD culture in Southeast Asia is Gojek's engineering approach during their rapid expansion phase. At peak growth, their engineering org was shipping dozens of deployments per day across multiple services. That's only possible with a pipeline that runs tests, builds containers, and deploys automatically — and an engineering culture that treats broken tests as a blocking problem, not a known issue to fix later.

The contrast case is a startup I've seen firsthand: three developers, one staging environment, manual deployments coordinated over WhatsApp. A feature could be "done" on Tuesday and live on Friday, if the right person was available and the deployment didn't require a hotfix halfway through. Engineering velocity wasn't limited by the quality of the developers — it was limited by the deployment process. Adding a fourth developer made it worse, not better, because now there was more code waiting in the same manual queue.

The deployment process is infrastructure for your team's output. If it's slow, everything downstream is slow. For a broader view of how deployment fits into your overall system, see [→ Read: What Is Software Architecture?].

FAQ

Q: Do we need DevOps from day one?

A: Not formally. In the earliest stages, one developer handling deployments manually is fine. The moment you have two or more engineers committing code regularly, automated CI becomes worth the setup cost. It prevents the "who broke the build?" conversation from becoming a weekly ritual.

Q: What does a DevOps engineer actually do?

A: They build and maintain the infrastructure that lets developers ship code reliably — the CI/CD pipelines, the container orchestration, the monitoring setup, the deployment tooling. At larger companies this is a dedicated role. At most startups, it's split across the engineering team, with one or two people owning the infrastructure.

Q: How do I know if our deployment process is too slow?

A: If a developer finishing a feature and that feature being live for users takes more than a day under normal circumstances, it's too slow. The benchmark for high-functioning teams is hours, sometimes minutes. The gap usually lives in manual steps, approval chains, or fragile environments that require careful handling.

Q: What is Docker, exactly?

A: Docker is the most widely used tool for creating and running containers. When your team says "we Dockerised the app," they mean they packaged it in a container that runs consistently regardless of where it's deployed. It's become the standard unit of deployment for most modern backend services.

Q: Why does adding more developers sometimes make shipping slower?

A: More developers means more code changes happening simultaneously, more potential conflicts when merging work, and more load on whatever deployment process you have. Without CI/CD, these problems compound. With it, they mostly don't — because the pipeline handles integration and deployment automatically, regardless of how many people are committing.

Slow deployments are a tax on every feature your team builds. The revenue impact is real: slower time-to-production means slower feedback, slower iteration, slower response to what users actually want. Most of the time, fixing this isn't a headcount problem — it's an infrastructure problem that a week of focused engineering work can substantially improve. If your team is spending more time coordinating deployments than shipping features, that's worth taking seriously.