DevOps Consulting

When you need a DevOps consultant

Companies usually get in touch when they recognize themselves in one of these signals:

• Fragile releases. Every release is a small gamble, you ship less often than you should and, when something goes wrong, rolling back is complicated.
• Hand-managed infrastructure. Environments configured by hand, little documentation, infrastructure and operational knowledge concentrated in one or two heads. Every change costs time and attention.
• Trouble adopting AI tools. The team would like to use AI agents on the infrastructure too, but without a solid context the agent has nothing reliable to work on.
• Cloud costs out of control. Spending grows faster than the product and nobody can say precisely where the money goes.

How I work

1. Assessing the situation

I start from how things actually are: how you release, how the infrastructure is managed, where the risks hide and how deeply DevOps practices are rooted in the team. This does not call for an endless audit. It calls for an honest snapshot to start from.

2. A plan with the right priorities

From there we build an action plan that separates what is urgent from what can wait and from what is not worth doing at all. In a startup or a scale-up the scarcest resource is the team's time, and the plan has to account for that.

3. Benefits first, tools second

Before talking about technology we focus on the outcome you want: more frequent releases, faster recovery, predictable costs, less dependence on individual people. Only then do we choose the tools: the CI/CD platform (GitLab CI, GitHub Actions), Infrastructure as Code (Terraform, Ansible), the GitOps model (Argo CD). Chosen because they fit the context, not because they are fashionable.

4. Implementation and team mentoring

I work side by side with the team: I implement things myself where it makes sense, review other people's work and act as a tutor until the practices become everyone's shared asset. The goal is to make myself redundant within a reasonable time. When the engagement ends, the team is able to maintain and evolve what we built together.

What you get

• A clear assessment of the starting point and a plan with priorities.
• Automated, repeatable and reversible releases.
• An infrastructure described as code, versioned and reproducible.
• Visibility into cloud costs and what drives them.
• A team able to work autonomously and a platform on which AI agents can operate safely too.

DevOps in the age of AI agents

AI makes it faster to change code and infrastructure. But if the platform is fragile, poorly documented or full of exceptions, it accelerates the risk as well. So you need to build a declarative, observable and understandable platform, so that people and AI tools can act on it with more confidence.

In practice this means giving agents two things:

• A harness. It is the agent's working environment: the context it reads (repositories, documentation, project conventions), the tools it can use (for example terraform plan, the tests, the cloud provider's CLI) and the way it proposes changes, normally a pull request. A good harness gives the agent the right information and a verifiable way to contribute.
• Guardrails. They are the limits that stop an agent, or a person, from doing damage: permissions kept to a minimum, changes only via pull request, mandatory automated plans and tests, separate environments, human approval for anything that touches production.

The same practices that make an infrastructure safe for agents also make it easier for people to manage.

How we work together

I work mostly remotely, with companies across Europe, remote-first. Strategy sessions and training workshops, on the other hand, can be in person. I take on a few clients at a time, usually two or three.

• Single session. A focused conversation about one specific decision: an audit, a second opinion, an architectural choice, the review of a project plan.
• Project. A well-defined piece of work, with a clear beginning and end: for example introducing GitOps or moving the infrastructure to Infrastructure as Code.
• Fractional engagement. Ongoing work alongside the team, for when the infrastructure is critical but a full-time senior hire is still premature.