Nobody owns cloud and security yet. We take it on.

Does this sound like your team?

• Our best backend engineer is also the DevOps person, and it is taking a growing share of their week.
• The contractor who set up the cloud account has moved on, and nobody is sure how it fits together.
• Deploys work when one particular person runs them.
• A customer asked who is responsible for security here, and we did not have a name.
• We are not ready to hire a full-time DevOps engineer, and we want this handled properly.

This is a common stage for a small engineering team. The work spans cloud, deployment and security, it does not yet fill a full-time role, and it still needs an owner. Can one person handle cloud, DevOps and security, or do you need three hires? sets out what fits under one owner and what does not.

What we do in the first two weeks

1. Days 1 to 3

   Map what exists

   With read-only access we inventory accounts, environments, pipelines, access and spend, and write down how production works today, including the parts that live in one person's head.

2. Days 4 to 5

   Agree who owns what

   You get a written ownership list based on our published ownership matrix: what MatrixGard owns, what is shared with your engineers, and what stays yours.

3. Days 6 to 10

   Close the gaps that carry the most risk

   Usually in this order unless your map says otherwise: secrets out of code, multi-factor on every human account, a backup restored once to prove it works, alerts routed to a named person, and a deploy that anyone on the team can run and roll back.

4. Days 11 to 14

   Set the rhythm

   A shared channel, a monthly written report on cost, changes and open risks, runbooks in your repository, and the incident rule stated plainly: production down gets a response at any hour, everything else the next business day.

If you want to start on your own, five DevOps practices for a startup with no DevOps engineer gives the order we would use.

What is in scope

• AWS, GCP and Azure accounts: structure, guardrails, baseline configuration
• Terraform and infrastructure as code, so changes go through review
• CI/CD: we build the pipeline and keep it working
• Kubernetes, where you run it
• Access, secrets, logging and monitoring
• Cloud cost, tracked and reported every month
• Vulnerability management for infrastructure and dependencies
• Technical readiness for SOC 2, ISO 27001 and DPDP, as a result of the above
• Help hiring your own DevOps engineer when the time comes: the job description, the technical interview and a written handover

Two situations this page is written for: production keeps breaking at night and nobody owns it, and engineers spend more time fixing deployments than building.

What this is not

• Not a staffed 24/7 operations centre. Production down is covered at any hour on every plan. Everything else is next business day.
• Not your application developers. We own the platform your code runs on. Your engineers own the code.
• Not a seat in your daily stand-up. It is ownership of the areas above, within the hours of your plan.
• Not a lock-in. Month to month, 30 days notice, and the code, runbooks and reports live in your repositories and accounts.
• Not a permanent substitute for a team you have outgrown. When a full-time hire becomes the right call, we say so and help you hire.

The signals that it is time to hire full-time: many deployments a day with engineers blocked on the pipeline, a need for a staffed on-call rotation, or an engineering team past roughly fifteen to twenty people. That threshold is our own working rule, not an industry figure.