DevOps for small teams: what to build first and what to skip

DevOps for a team of one to five is not a scaled-down copy of what a fifty-person engineering department does: it is a different discipline with different priorities. You need a pipeline that ships every change the same way, a staging environment that resembles production, backups you have actually restored, and alerts that wake a human only when something real is wrong. Everything else, including most of what conference talks tell you to build, can wait until you are bigger.

Why does DevOps matter when there are only two of you?

Because at that size, every hour spent firefighting is an hour taken directly from building the product. A large company can absorb a botched release; a two-person team loses its whole week to one. The point of DevOps at small scale is not velocity theatre: it is removing the category of problem where a deploy depends on remembering seven manual steps, or where the only person who knows how production works is on holiday.

The other reason is the bus factor. When the entire operational knowledge of a business lives in one founder's head, the business is one illness or one resignation away from being unable to ship. Written-down, automated operations are how a tiny team stops being fragile.

What does a minimum CI/CD pipeline look like?

For most small teams the answer fits on an index card: every push runs your tests and linter automatically, and merging to your main branch deploys, either straight to production or behind a single manual approval. Hosted runners such as GitHub Actions and GitLab CI make this an afternoon of work for a typical web application.

Three habits matter more than the tooling:

• One path to production. Nobody deploys from a laptop. If the pipeline is the only way code ships, the pipeline is always trustworthy.
• Fast feedback. Keep the test stage quick enough that people run it willingly. A slow pipeline gets bypassed, and a bypassed pipeline is worse than none.
• Reversibility. Know, before you need it, how to roll back: redeploy the previous build, flip a feature flag, or restore a database snapshot. Practise it once on a calm day.

Skip the exotic parts. Canary releases, blue-green infrastructure and progressive delivery solve problems of scale you do not have yet. A plain pipeline that always works beats a sophisticated one that only its author understands.

Do you really need a staging environment?

Yes: one, and only one. A staging environment is where migrations, integrations and risky changes get rehearsed against production-like conditions before customers see them. Without it, production becomes your test environment, and your users become your testers.

Keep it honest and keep it cheap. Honest means the same runtime versions, the same environment-variable shape, and data that is realistic in structure: seeded or properly anonymised, never a raw copy of customer records, which quietly creates a privacy and compliance problem. Cheap means small instances, and turning it off outside working hours if your platform bills by the hour. What you should not do is accumulate a zoo of per-developer environments; at this size, the coordination cost of one shared staging environment is minor and the savings are real.

Backups are worthless until you have restored one

Automated backups are table stakes: your database on a daily schedule at minimum, plus anything customers upload, and the configuration and secrets needed to rebuild the application itself. Most managed database services make the backup half nearly effortless, which is exactly why teams stop there.

The question is never "do we have backups?" It is "how long would it take us, today, to stand everything back up?"

The restore drill is the part that counts. Once a quarter, take a recent backup and restore it somewhere isolated, such as a scratch database or a spare project, and time yourself. The first drill almost always surfaces something: a missing secret, an undocumented step, a backup job that has been silently failing for months. Better to find that on a Tuesday afternoon than during an outage. Write the restore steps down as you go, because the person doing the real restore will be stressed, and possibly not the person who wrote the backup job.

Two refinements are worth the small effort: keep at least one copy outside your primary cloud account, so a compromised or locked account does not take your backups with it, and set an alert on the backup job itself so a failure is loud rather than silent.

What should monitoring and alerts cover?

Start from the user's chair and work backwards. The signals that matter are the ones customers feel: is the site up, are requests failing, are they slow, is a queue of background jobs quietly growing? An uptime check on your key endpoints, an error tracker such as Sentry, and the basic metrics your hosting platform already collects will cover a small product surprisingly well.

Alerting discipline matters more than alerting coverage. Every alert should be actionable and urgent; anything that is merely interesting belongs on a dashboard or in a daily digest, not in someone's pocket at 3 a.m. When a noisy alert fires repeatedly without requiring action, fix it or delete it. Alert fatigue is how small teams end up ignoring the one page that mattered.

Also decide, explicitly, what happens when an alert fires outside working hours. A formal on-call rotation is overkill for three people, but "whoever sees it first" is a plan for it going unseen. A simple agreement about who is reachable this week, and what genuinely justifies a phone call, is enough.

How much infrastructure as code is enough?

Full infrastructure as code, with every resource in Terraform or an equivalent applied only through the pipeline, is the right destination, but it is a heavy first step for a tiny team. The lite version captures most of the value: define your application environments in code, keep every configuration value and script in version control, and never make an undocumented change in a cloud console. If you click something, record it. The cloud and hosting approach you sit on top of shapes how much there is to codify in the first place.

Platform-as-a-service products (Render, Fly.io, Railway, Heroku and their peers, current at the time of writing) are a legitimate part of this answer, not a compromise. Letting the platform own servers, TLS and deploy mechanics is often the most professional choice a small team can make, because it shrinks the surface you have to operate at all.

What can you safely skip until you are bigger?

Quite a lot, and skipping it is a decision to be proud of rather than embarrassed by:

1. Kubernetes. It solves coordination problems between many services and many teams. With one application and five people, it adds a full-time operational hobby.
2. Microservices. A well-structured monolith is faster to build, deploy and debug at this size. Split services when a real boundary demands it, not in anticipation.
3. Service meshes, internal developer platforms and multi-region active-active setups. These are answers to questions you have not been asked yet.
4. Elaborate observability stacks. Self-hosting a metrics, logging and tracing suite is a project in itself. Hosted tools on modest plans do fine.
5. A formal on-call rota with escalation tiers. Replace it with the simple agreement described above until headcount forces the issue.

The pattern behind every item is the same: complexity you adopt is complexity you operate, patch and explain to every future hire. Small teams win by keeping the operated surface small.

How OlDevs helps

OlDevs is a full-stack technology studio in Vancouver, building and running software since 2014. Our full-stack development work includes exactly this kind of foundation: pipelines, staging, backup and restore procedures, and monitoring set up as part of the build, not bolted on afterwards, with a working demo every week so you can see it operating, and every account, credential and line of code owned by you from day one. Whether you are starting a product or inheriting one with no operational safety net, we can put the essentials in place and document them so your team can run them without us. Tell us where things stand and request a quote through our contact page; we reply to every enquiry within one business day.