Foldnine Start with an audit

Foldnine · DevOps and SRE consulting

Nobody owns
the platform.

When a team ships faster than it can staff its infrastructure, the parts nobody sees get deferred — until an incident finds them first. We read the systems as they actually are and write them down: what breaks next, what to fix, and in what order.

Start with an audit See the work

The situation

The migration is already
in flight.

The platform role has been open since spring. The move to Kubernetes started anyway, because it had to. So it is being done by the same people who own the product roadmap.

What gets deferred is never the visible part. It is autoscaling behaviour, PodDisruptionBudgets, what happens to in-flight requests during a node roll — the things that cost nothing to ignore until the night they cost everything. None of that needs a full-time hire to find. It needs someone to look, on purpose, and write it down.

The work

Three ways in,
smallest first.

Most engagements start with the audit, because it is the smallest thing to say yes to and because a fixed price on an unclear scope is a guess. The audit is how the scope stops being unclear.

  1. 01

    Infrastructure audit

    Start here

    A few days. We review the setup you actually have — the running configuration, not the diagram of it — and finish with a written report: what breaks first, what to fix, and in what order, with an honest effort estimate against each item. The report is yours whether or not we work together afterwards.

    Length
    A few days
    Output
    Written report
    Needs
    Read access, one call
  2. 02

    DevOps improvement sprint

    Bounded

    One piece of work with a defined outcome and an end date: a deployment pipeline, infrastructure as code for an environment, an observability baseline, a step of a migration. Scoped from the audit or from a problem you have already diagnosed yourself.

    Shape
    One outcome, one end date
    Typical
    pipeline · IaC · observability
    Scoped by
    audit, or your own diagnosis
  3. 03

    Fractional DevOps / SRE

    Ongoing

    Part-time ownership of infrastructure for a team that has nobody in the role and does not yet need somebody full time. Someone whose job it is to care about the boring parts on a Tuesday, rather than at three in the morning.

    Shape
    Monthly, part time
    For
    No one in the role
    Ends
    when you hire

The audit, in detail

A document,
not a meeting.

The deliverable is a written report you can forward to someone who was not in the room — a CTO, a board, the engineer who inherits it. That is the point of writing it down.

01 · Access

What we need

  • Cloudread-only
  • Reposread access
  • Peopleone call, one hour

No production changes are made during an audit.

02 · What we read

  • The running configuration, not the diagram
  • Pipelines, and who is able to run them
  • The last few incidents, and what was changed after
  • The bill, by service and by environment

03 · What you get

The report

  • Findingsranked by what fails first
  • Each withevidence, effort, risk
  • Orderwhat to do first

Yours to keep, act on, or hand to someone else.

04 · After

No obligation

Plenty of reports end with "your team can do all of this". If that is the honest answer, it is the one in the document. The audit is not a qualifying call with a price on it.

What we actually
look at.

Not a certification list. These are the places the problem usually turns out to be.

  • 01Kubernetes and what it does under load
  • 02Deploys, rollbacks and release safety
  • 03Infrastructure as code, and its drift
  • 04Observability that answers questions
  • 05Cloud cost, by service and environment
  • 06On-call, and whether anyone sleeps

The common thread is ownership. Almost every finding starts as nobody's job and ends as an incident.

How we work

Answer the question first.
Pitch second, if at all.

  1. If you do not need us, we will say so

    It is the single most credible thing we can tell you, and it costs one engagement and earns the next. A report that concludes your own team should do this is a report that did its job.

  2. A range, and what moves it

    Until the scope is actually known you get a range, not a number, and the reason it is a range — how many environments, whether the IaC exists today. A fixed price on an unclear scope is a guess dressed as a quote.

  3. Whoever scopes the work does the work

    The engineer who reads your systems is the one who writes the report and, if it goes further, the one who does the work. Nothing is won in a meeting and handed to somebody who was not in it.

  4. Written down, so it survives the call

    Findings come with the evidence they rest on, so you can disagree with a specific line rather than with a verdict. Anything we cannot show you the evidence for is marked as the inference it is.

This is for you if

  1. Infrastructure is somebody's second job
  2. A migration is in flight
  3. The DevOps role has been open a while
  4. Deploys need one specific person awake
  5. The cloud bill grew and nobody knows where

Usually 10–100 engineers, no platform team.

Probably not, if

  1. You have a platform team already
  2. You want a body for a headcount gap
  3. You need 24/7 on-call cover
  4. The decision is really about price

Say so early and we will tell you straight.

Tell us what is slow
or breaking.

Start a conversation What the audit covers

A description of what is slow or breaking is enough to start — no brief required. English or Serbian.