If you are looking for the DevOps practices for a startup with no DevOps engineer, the short answer is five, adopted in a fixed order: get secrets out of the code, run CI on every merge, automate deploys with a rehearsed rollback, put monitoring under a named owner, and move infrastructure into version control. Done in that order, a team of five to twenty engineers can have all five running within roughly a month of part-time effort, without hiring anyone.
This post is for the founder or first engineering lead who has no DevOps hire, knows the current setup is fragile, and wants a ranked list rather than a glossary. Most articles on DevOps practices list twenty capabilities with equal weight. That is accurate and useless to a team whose infrastructure is owned by whoever touched it last. What you need is the order, the rough cost of each step in engineering hours, and what breaks if you skip it.
Two related posts cover the pain around this. Engineers spend more time fixing deployments than building measures the deployment tax, and no DevOps person, and production keeps breaking at night compares the options for incidents. This one is the build order that prevents both. Where I give a practitioner read rather than a cited source, it is labelled inline.
Quick context: what the research actually measures
The most cited body of work on delivery practice is DORA, the research programme now run out of Google Cloud. DORA's current model tracks five software delivery metrics, grouped into throughput (change lead time and deployment frequency) and instability (change fail rate, failed deployment recovery time, and deployment rework rate), per its metrics guide. The rework rate is the newest; DORA's history of the metrics calls its 2024 addition the most significant structural change to the set.
The gap between the best and worst teams is not small. In the 2024 report's clusters, as summarised by Octopus Deploy, elite teams had change lead times under a day, a change fail rate around 5%, and recovery from a failed deployment in under an hour. None of that requires a platform team. It requires a handful of habits that make a deploy boring, and boring is exactly what a team without a DevOps engineer cannot currently afford to skip.
DevOps practices for a startup with no DevOps engineer: the five, compared
DevOps practices for a startup with no DevOps engineer are the small set of habits that let a product team ship and recover safely without anyone whose job is infrastructure. The deciding rule for the order is simple: do first whatever is cheapest and whose failure cannot be undone. A leaked key cannot be un-leaked; a slow deploy can be fixed next month.
| Practice | What it replaces | Failure it prevents |
|---|
| Secrets out of code | Keys in the repo or in a shared doc | A credential leak you cannot reverse |
| CI on every merge | "It worked on my machine" | Broken main discovered in production |
| Deploys with rollback | One person who knows the steps | A bad release with no fast way back |
| Monitoring with an owner | Customers reporting the outage | Silent failures nobody is paged for |
| Infrastructure as code | Console clicks nobody wrote down | An environment nobody can rebuild |
1. Get secrets out of the code first
The first practice is the cheapest and the only one whose failure is permanent. GitGuardian's State of Secrets Sprawl 2025 counted 23.8 million secrets leaked on public GitHub in 2024, up 25% on the year, and found that 70% of secrets leaked in 2022 were still active. The same report found plaintext secrets in 35% of the private repositories it scanned, so "our repo is private" is not a control.
The fix is unglamorous. Move every credential into a managed store and read it at runtime. On AWS, Secrets Manager costs $0.40 per secret per month plus $0.05 per 10,000 API calls, with a 30-day trial per secret, so a startup with thirty secrets pays about $12 a month. Then turn on GitHub push protection, which blocks a recognised secret before it lands in the repository, and rotate anything that has ever been committed, because deleting the line does not delete the history.
Practitioner opinion: for a typical seed-stage codebase this is half a day of work, most of it finding where the keys live. Skipping it is the one omission on this list that can end a company rather than slow it down.
Takeaway: rotate every key that has ever touched Git, then make the store the only place keys exist.
2. Run CI on every merge
Continuous integration means every change is merged often and verified automatically, so a broken main branch is found in minutes rather than in production. DORA's continuous integration capability describes regular check-ins, each triggering automated tests that catch regressions quickly, and it sits underneath almost every other technical capability in their model.
The cost is low because the tooling is close to free at startup scale. GitHub's included usage gives the Free plan 2,000 Actions minutes a month for private repositories, and public repositories on standard hosted runners are free. A pipeline that runs lint, unit tests and a build in under ten minutes fits comfortably inside that for most small teams.
What matters more than the tool is the rule: nothing merges to main unless the pipeline is green, and a red pipeline is fixed before new work starts. Teams that skip the rule end up with CI that runs and is ignored, which is worse than no CI because it creates false confidence.
Practitioner opinion: one to two days to set up a useful first pipeline, then an hour a week of upkeep. Start with the checks that already pass locally. Add slower suites only once the fast ones are trusted, and quarantine flaky tests rather than re-running them, a point the deployment tax post covers in detail.
Takeaway: a green pipeline is the merge gate, not a suggestion.
3. Automate deploys, with a rollback you have rehearsed
Deployment automation means a release runs the same scripted path every time, in every environment, with no hand-typed steps. DORA's deployment automation guidance recommends keeping deployment scripts and environment configuration in version control and using the same process for every environment, including production, so the process is tested many times before it touches customers.
Rollback is the half most teams skip. If going back is slow or risky, deploys get larger and rarer, and larger deploys fail in more interesting ways. Most managed platforms now ship a rollback switch you only have to turn on. Amazon ECS, for example, offers a deployment circuit breaker that marks a deployment failed when tasks do not reach a healthy steady state and, with rollback enabled, returns the service to the last deployment that completed successfully. It applies to the rolling update deployment type.
The rehearsal is the part that costs time and pays most. Deliberately ship a broken build to staging, confirm the rollback fires, and time it. A rollback nobody has watched work is a hope, not a control.
Practitioner opinion: two to four days for a single service, depending on how many manual steps the current release has. Database migrations are where it gets hard; make them backwards compatible so the previous version of the app can still run against the new schema.
Takeaway: if you have not seen the rollback fire, you do not have one.
4. Put monitoring under a named owner
Monitoring without an owner is a dashboard nobody opens. The practice has two halves: measure what users feel, and make one named person responsible for responding when it goes wrong. Google's SRE book recommends the four golden signals, latency, traffic, errors and saturation, as the metrics to focus on if you can only measure four for a user-facing system, and advises paging a human on symptoms users experience rather than every internal blip.
DORA's monitoring and observability capability adds a point small teams miss: deploy the monitoring configuration through the same pipeline as the code, so alerts stay valid when the system changes.
The owner is the hard part for a team with no DevOps engineer. The SRE book's chapter on being on-call caps operational work at 50% of an engineer's time and targets a maximum of two incidents per 12-hour shift. Those numbers are for a mature team, but the principle transfers: if one engineer is absorbing every page, the load is invisible and it will burn them out.
Practitioner opinion: one to two days to set up the signals and alert routing, then a written weekly rotation with a named owner and a named backup. The rotation is the practice. The tool is a detail.
Takeaway: every alert routes to a person with a name, and the name changes on a schedule.
5. Move infrastructure into version control
Infrastructure as code means servers, networks, databases and permissions are defined in files under version control, and changed by running those files rather than by clicking in a console. DORA's version control capability says teams should keep not just source code but deployment scripts and infrastructure and application configuration under version control, which supports disaster recovery and auditability.
This is last in the order because it is the most expensive, not the least important. Converting an estate that grew through console clicks takes real time, and the payoff arrives the day you need to rebuild an environment, review a change, or answer an auditor asking who opened a port.
Tooling is no longer a blocker. Terraform remains the common choice, and OpenTofu, the Linux Foundation fork created after HashiCorp moved Terraform to the Business Source License in August 2023, is positioned as a drop-in replacement and reached general availability in January 2024. Pick one and handle its state carefully; our Terraform state post covers how.
Practitioner opinion: do not attempt a big-bang import. Start with new resources only: from today, anything new is created in code. Then import existing resources one area at a time, starting with networking and IAM. Expect one to three weeks spread over a quarter.
Takeaway: start with new resources, and let the console become read-only over time.
6. Why this order, and not the textbook order
Textbooks usually start with version control and infrastructure as code because everything else builds on them. That is the right dependency order for a greenfield platform. It is the wrong priority order for a live product with no DevOps engineer, where the question is which failure you can least afford this quarter.
Practitioner opinion: rank by two factors, the cost to adopt and whether the failure it prevents is reversible. Secrets win on both: hours of work, and a leak cannot be taken back. CI is next because it is cheap and makes every later step safer to change. Deploys with rollback come third because they depend on CI producing a trusted build. Monitoring is fourth because alerts are only actionable once you can roll back what they catch. Infrastructure as code is last because it is the largest job and can be done incrementally while the other four protect you.
Most teams already use Git for application code, so the version control foundation the textbooks insist on is usually half in place. The missing half is infrastructure, which is exactly why it sits at the end of this list rather than the start.
Takeaway: order by irreversibility and cost, not by the architecture diagram.
7. What to skip for now
The fastest way to stall this list is to add things to it. Practitioner opinion: a team of five to twenty engineers without a DevOps hire should defer Kubernetes unless a managed container service genuinely cannot run the workload, defer a service mesh, defer multi-region active-active, and defer a formal SLO programme with error budgets until the four golden signals are being watched by a named owner.
None of these are bad ideas. Each one adds operational surface that someone must own, and the premise of this post is that nobody owns infrastructure yet. Adopting them before the five basics produces a sophisticated platform that one engineer understands, which recreates the single point of failure the basics were meant to remove.
The test for adding anything new is the same as for the five: what does it cost in hours, who will own it, and what reversible or irreversible failure does it prevent. If you cannot name the owner, it is not time.
Takeaway: every new tool needs an owner before it gets a ticket.
8. How to tell whether it is working
Measure before and after, or the work will be judged by feel. The five DORA metrics in the metrics guide are the right yardstick, and a small team can approximate them from the tools it already has: deploy count and lead time from the CI history, change fail rate and rework from the incident log, recovery time from alert timestamps.
Practitioner opinion: take a baseline in the first week, before practice one, and check monthly. The early signals that the order is working are deploys getting smaller and more frequent, fewer unplanned fixes after a release, and recovery measured in minutes rather than hours. A metric that does not move after a practice lands is a sign the practice exists on paper but the rule behind it is not enforced.
Takeaway: write the baseline down before you change anything.
9. Why AI coding tools make this more urgent, not less
AI assistants raise the volume of change, and every one of the five practices is a control on change. The 2025 DORA report, State of AI-assisted Software Development, drew on survey responses from nearly 5,000 technology professionals, and its central finding is that AI acts as an amplifier: it magnifies the strengths of high-performing organisations and the dysfunctions of struggling ones.
The secrets data points the same way. TechRadar's write-up of GitGuardian's next edition reports about 29 million secrets exposed on GitHub in 2025, a 34% rise, and says AI-assisted commits leaked at roughly double the baseline rate.
For a team with no DevOps engineer, that means the basics are the precondition for using AI tools safely. More pull requests need a CI gate, more deploys need a rollback, and more generated code needs push protection in front of it.
Takeaway: if the team is shipping more code with AI, adopt the five sooner.
10. When doing it yourself stops being the answer
Every practice here can be adopted by the existing team. The ongoing ownership is the part that tends to fail. Practitioner opinion: the signal is when the rotation in practice four keeps landing on the same one or two people, or when nobody can say who reviews infrastructure changes.
At that point the options are a full-time hire, a managed service, or a fractional engagement, compared in detail in the production-breaks-at-night post. For reference, MatrixGard's published Starter tier on matrixgard.com/pricing is $2,500 a month. If your team has the hours and a willing owner, doing it yourself is the right call, and this list is designed to make that possible.
Takeaway: the decision is about ownership, not capability.
Summary: the five practices, in order
| Order | Practice | Rough effort | If skipped |
|---|
| 1 | Secrets out of code | Half a day | A leaked key that stays valid |
| 2 | CI on every merge | One to two days | Broken main found by customers |
| 3 | Deploys with rollback | Two to four days | Large, rare, frightening releases |
| 4 | Monitoring with an owner | One to two days | Outages reported by users |
| 5 | Infrastructure as code | Start with new resources | An environment nobody can rebuild |
Effort figures are practitioner opinion for a single product at seed stage, not measured benchmarks.
What to do at your stage (practitioner opinion)
Pre-seed, under five engineers. Practices one and two this month. Add a one-command rollback even if the deploy itself is still partly manual.
Seed, five to twenty engineers. All five within a quarter, in order, with the rotation written down and infrastructure as code started on new resources.
Series A, or regulated from the start. All five enforced, plus a baseline of the DORA metrics reviewed monthly, because an auditor or enterprise customer will soon ask how changes reach production.
If you want a second pair of eyes on where your team sits against these five, MatrixGard runs a free 20-minute review for early-stage founders, funded or bootstrapped. Start with the security checklist.
Avinash S is the founder of MatrixGard. Fractional DevSecOps for early-stage startups, funded or bootstrapped across India, the GCC, the UK, and the US. Almost a decade of building, breaking, and securing cloud infrastructure for fintech, healthtech, and SaaS workloads.
Methodology note. This post answers devops practices for a startup with no devops engineer as a ranked list, and does not cite any engagement of ours. Capability definitions are from DORA's pages on continuous integration, deployment automation, monitoring and observability, and version control; the five delivery metrics and the 2024 rework rate addition are from DORA's metrics guide and metrics history. The 2024 performance cluster figures are as summarised by Octopus Deploy. The 2025 AI findings are from DORA's report page and Google Cloud's announcement. Secrets figures are from GitGuardian's 2025 report and TechRadar's coverage of the following edition. Prices and allowances are from the AWS Secrets Manager pricing page and GitHub's included usage reference; rollback behaviour is from the Amazon ECS documentation. Monitoring and on-call guidance is from Google's SRE book. OpenTofu history is from its FAQ and the Linux Foundation. The order of the five, the effort estimates and the stage advice are practitioner opinion. No client outcome, testimonial or price other than MatrixGard's published one appears in this post.
