DevOps for growing companies: where to start

You do not need a platform team or Kubernetes to start doing DevOps. You need a few habits, added in the right order. Here is that order, how to measure progress and when to bring in help.

Updated 6 October 20268 min readBy Effred editorial team

What DevOps means for a growing team

DevOps is not a job title or a tool you buy. It is a way of working in which the people who build software also share responsibility for releasing and running it, with enough automation that both are safe and routine.

For a growing company the problems it fixes are familiar. Releases that only one person knows how to do. A deploy nobody dares to run on a Friday. A server nobody can rebuild. Customers who notice an outage before you do.

The roadmap below is staged. Each stage pays for itself before you start the next, so skip ahead only when a stage is genuinely done.

Stage 1: Version control and a simple branching model

Put everything in Git: application code, configuration, database migrations, infrastructure scripts and runbooks. Keep the repositories in an organisation your company owns, not in a developer’s personal account.

Protect the main branch, so every change arrives through a pull request with at least one review.
Keep branches short-lived. DORA’s guidance on trunk-based development is three or fewer active branches, merged into trunk at least once a day.
Hide unfinished work behind feature flags instead of long-running branches.
Turn on secret scanning, and move any passwords or keys out of the code.
Tag every release, so you always know exactly what is running in production.

Stage 2: Continuous integration with automated tests

Every push should trigger a build and the tests, in GitHub Actions, GitLab CI or similar. DORA’s guidance is that tests should give feedback within a few minutes, with an upper limit of about ten, and that a broken build is fixed — or the change reverted — before anything else.

You do not need full test coverage to start. Begin where mistakes cost most:

Unit tests on the business rules that handle money or compliance: pricing, invoicing, GST, payroll and leave calculations.
A handful of end-to-end tests on the journeys that earn revenue, such as sign-up, checkout and payment.
Linting and type checks, which catch whole classes of bugs for very little effort.
A team rule that new code arrives with tests.

Then extend CI into continuous delivery. Deploy to staging automatically after every merge, make production a one-step deploy anyone on the team can run, and make rollback just as easy. If testing is the bottleneck, a QA team that joins your sprints can write the automation while your developers keep building.

Stage 3: Infrastructure as code

Ask one question: if your production server disappeared tonight, could you rebuild it from scripts by morning? If the honest answer is no, this stage matters.

Describe cloud resources in Terraform, or in OpenTofu, an open-source fork of Terraform hosted by the Linux Foundation.
Use Ansible or a similar tool for the server configuration you cannot avoid.
Store state remotely with locking, and review infrastructure changes through pull requests, like code.
Start with new resources, then bring existing ones under code gradually.

The payoff comes quickly: a staging environment that really matches production, disaster recovery you can rehearse, and no more servers that only one person understands.

Stage 4: Containers, but only when they help

Containers solve real problems: environments that differ between laptops and servers, many services with different runtimes, and the need to scale fast. Kubernetes also brings real work — upgrades, networking, security and someone who understands all three. Match the platform to your team, not to what large companies use.

Your situation	A sensible choice
One or two web applications and a small team	A managed platform or serverless containers, such as Amazon ECS with Fargate, Azure Container Apps or Google Cloud Run
Several services, steady traffic and someone who owns the platform	Managed Kubernetes: Amazon EKS, Azure Kubernetes Service or Google Kubernetes Engine
A legacy application on a virtual machine that rarely changes	Leave it on the virtual machine, built with infrastructure as code and patched on a schedule

You can always move to Kubernetes later. Moving off it, once you have built around it, is much harder.

Stage 5: Monitoring and alerts people trust

Prometheus, an open-source monitoring and alerting toolkit, collects metrics as time series; its Alertmanager routes the alerts; Grafana turns the data into dashboards. Together they are a common, low-cost place to start.

Google’s SRE book suggests watching four golden signals for every user-facing service — latency, traffic, errors and saturation — and paging people only for problems that are urgent, actionable and visible to users.

Alert on symptoms users feel, such as error rates, slow pages or failed payments, not on every CPU spike.
Link every alert to a short runbook: what it means and what to check first.
Add uptime checks from outside your own network.
Centralise logs and keep them for at least 180 days, as CERT-In’s 2022 directions require; an Indian region is the simplest choice, and logs of financial transactions must stay in India.
Add error tracking to your applications, so you see exceptions with their context.
Once the basics are steady, set service level objectives and alert when you are using up your error budget too fast.

If you need this set up quickly, our DevOps team configures dashboards, alert rules and on-call routing, and can stay on to watch them with you. When you want alerts to lead to action rather than a page at 3 a.m., Effred SIM puts autonomous AI agents on the same signals; our guide to choosing an AI monitoring solution explains what to check.

Stage 6: Incident response and on-call

A fair on-call rota, with a primary and a backup, handovers at a fixed time, and time off after a bad night.
Severity levels agreed in advance, with a response target for each.
One incident lead per incident, who coordinates while others fix.
A customer message template and a status page, so your support team is not guessing.
Blameless postmortems after significant incidents. Google’s SRE book describes them as finding the contributing causes without blaming any individual or team.
Regulatory steps in the runbook. CERT-In expects specified cyber incidents to be reported within six hours, and a personal data breach brings its own duties under the DPDP Rules. Decide now who reports and what they need.

A small team in one time zone will get paged at night. If that is wearing people down, bring in 24×7 support for out-of-hours cover rather than burning out your best engineers.

Stage 7: DevSecOps basics

Security belongs in the pipeline, not in a review at the end. You do not need a separate team to start:

Secrets in a vault or your cloud’s secrets manager, rotated on a schedule.
Dependency scanning, with automatic pull requests for updates.
Static analysis and container image scanning in CI, failing the build for serious issues.
Short-lived credentials for your pipelines instead of long-lived cloud keys.
Multi-factor authentication on code hosting and cloud accounts, with audit logs switched on.
A software bill of materials (SBOM) for each release. CERT-In has published technical guidelines on SBOMs, now at version 2.0 (July 2025).
Regular checks against common web weaknesses such as the OWASP Top 10.

Measure progress with the DORA metrics

DORA, the long-running research programme on software delivery, is best known for its four keys: deployment frequency, lead time for changes, change fail rate and time to restore service. Two updates are worth knowing. In 2023 DORA renamed time to restore to failed deployment recovery time, to focus on failures caused by changes. In 2024 it added a fifth metric, deployment rework rate.

Metric	What it measures	Where to get it
Deployment frequency	How often you deploy to production	The deploy history in your CI/CD tool
Change lead time	Time from a commit to that change running in production	Commit and deploy timestamps
Change fail rate	Share of deployments that need immediate intervention, such as a rollback or hotfix	Deployments tagged as needing a fix
Failed deployment recovery time	Time to recover from a deployment that fails	Your incident tracker
Deployment rework rate	Share of deployments that are unplanned and made because of a production incident	Hotfix deployments, tagged as such

DORA’s advice on using them is worth following: measure per application or service, do not turn the numbers into targets, look at trends rather than comparing teams, and start with a conversation and its Quick Check before building dashboards.

A simple maturity table

Use this to see where you are. Pick the row that hurts most and move it one column to the right. Do not try to be strong everywhere at once.

Area	Starting out	Getting there	Strong
Releases	Manual, done by one person, monthly or less	Scripted, anyone on the team can release	Automated and on demand, with a one-step rollback
Testing	Manual, before big releases	Unit tests in CI, a few end-to-end tests	Tests gate every merge, and flaky tests get fixed fast
Infrastructure	Built by hand	New resources defined as code	Every environment rebuilt from code
Monitoring	Customers report outages	Uptime checks and basic dashboards	Alerts tied to service level objectives, with runbooks
Incidents	Whoever notices, fixes	On-call rota and severity levels	Blameless postmortems with tracked actions
Security	Shared passwords, keys in code	Secrets manager and multi-factor authentication	Scans in CI, SBOMs, short-lived pipeline credentials

When to hire, and when to bring in a partner

Hire a DevOps or platform engineer when there is a steady stream of infrastructure work, several services to look after and an on-call load that needs an owner. Over time, make sure more than one person can do the work: someone who knows everything alone becomes a bottleneck, and a risk whenever they are on leave.

Bring in a partner when you need the foundations built quickly and handed over, when you need 24×7 cover you cannot staff, during a cloud migration, or before a big launch or investor due diligence. A good engagement:

Starts with a review of how you build, test and release today.
Fixes the slowest and riskiest steps first.
Leaves everything in your own repositories and cloud accounts.
Documents what it builds and trains your team to run it.
Has a clear end, or a clear monthly scope if it continues.

You can also mix the two: a partner sets up pipelines, infrastructure as code and monitoring, while the team builds its own skills or adds engineers through staff augmentation.

Common questions

Where should a startup start with DevOps?

With version control and continuous integration: every change in Git, reviewed through a pull request, and built and tested automatically. Then automate deployments, describe your infrastructure as code and add monitoring. Containers and Kubernetes can wait until they solve a real problem.

What are the DORA metrics?

DORA’s four keys are deployment frequency, change lead time, change fail rate and failed deployment recovery time (formerly time to restore service). Since 2024 DORA has also tracked a fifth metric, deployment rework rate.

Do we need Kubernetes?

Often not at first. One or two applications usually run well on a managed platform or serverless containers. Kubernetes earns its keep when you have several services, steady traffic and someone who owns the platform.

How long does it take to set up a CI/CD pipeline?

For one application, a basic pipeline is quick to set up; most of the time goes into writing tests and making deployments repeatable. In our DevOps engagements the review takes about a week or two, and a reliable pipeline with basic alerting usually follows in the next sprints.

Should we hire a DevOps engineer or use DevOps services?

Hire when there is steady infrastructure work and an on-call load that needs an owner. Use a partner to set up the foundations quickly, cover out-of-hours support or help during a migration, with everything left in your accounts and documented for your team.

Sources

First published 5 October 2026. Spotted something out of date or unclear? Email info@effred.com and we will look at it.