Service · Software development

Hire a DevOps developer with team backup.

A DevOps engineer or consultant who gets your CI/CD, infrastructure-as-code and cloud platform in order, with a senior colleague behind the scenes for review and continuity. A dedicated specialist from our Dutch team, not a loose freelancer you hope will hand over the pipeline keys neatly.

Not a freelance script kiddie. A DevOps consultant with a safety net.

When you look for a DevOps engineer or consultant, the first instinct is often a freelancer via a platform or recruiter. Quickly available, often experienced on paper, done. Until you discover that the pipeline runs on a personal GitHub account, the Terraform state sits in a Dropbox folder, and nobody knows what happens if that one engineer becomes unreachable. At that point the cloud bill has exploded, the deployment is broken, or worse, the production database is only accessible via a personal SSH key that nobody can rotate.

We provide a DevOps developer as part of our software development team: full-time on your project, but with peer review on every infrastructure change, a replaceable position within the team, and a contract that clearly assigns ownership of pipelines, IaC and keys. What we build is transferable by design: all infrastructure in Terraform or similar IaC, all pipelines in code, all secrets in a vault, and no "only Frank knows" knowledge hidden in someone's head.

We work in the Netherlands, in Dutch time zones, with communication in Dutch or English, as you prefer. In the event of a production incident at four in the afternoon, you are not waiting in a ticket queue in another time zone; someone from our team is ready. For on-call rotations and incident response, we set up structures that keep working even when we are no longer involved.

The types of assignments we excel at: cloud platforms on AWS, GCP and Azure, container platforms on Kubernetes or ECS, CI/CD pipelines for teams of five to fifty developers, observability stacks with Prometheus, Grafana and Datadog, and migration projects from on-premises or a legacy stack to a modern cloud environment. For pure security research or compliance-only assignments, other specialists are better suited, but for anything that runs, keeps running and changes in production, we are in our comfort zone.

What our DevOps engineers do.

Three main directions in which a DevOps developer adds the most value with us, depending on where your organisation currently stands.

Direction 01

CI/CD pipelines and automation

Building or reorganising the software delivery pipeline: from git push to production deployment, with automated tests, build caching, security scans and zero-downtime releases. We work with GitHub Actions, GitLab CI, Jenkins, CircleCI and ArgoCD for GitOps. This includes environment strategy (dev, staging, production), feature flags, and rollback procedures that are genuinely tested. Many teams call us in because their current pipeline is slow, often red, or nobody dares touch it any more. Often intertwined with a legacy software replacement project where the old release flow simply no longer fits the new architecture.

GitHub ActionsGitLab CIJenkinsCircleCIArgoCD
Direction 02

Infrastructure-as-code and cloud platforms

The full cloud infrastructure as code: VPCs, IAM, databases, queues, container clusters, secrets management. We work with Terraform, Pulumi, OpenTofu and CloudFormation, and where it makes sense we build a cloud-native platform on which your own developers can deploy services themselves. Includes multi-environment setup, drift detection, and modules your team can reuse. For teams that want their own internal developer platform (IDP), often because setting up new services by hand has become too slow, we deliver platform engineering work based on Backstage, Crossplane or a custom abstraction.

TerraformPulumiOpenTofuAWS & GCP & AzureBackstage
Direction 03

Containers, Kubernetes and observability

Container platforms on Docker, Kubernetes (EKS, GKE, AKS), ECS or a lighter option such as Nomad or Fly.io. Includes Helm charts, ingress configuration, a service mesh where it adds value, and networking that remains easy to explain even a few years from now. On top of that sits the observability layer (logging, metrics, traces) built with Prometheus, Grafana, Loki, Tempo, Datadog or New Relic. As standard: SLOs per service, alert routing to the right on-call engineer, and dashboards that won't be forgotten after six months. For mid-market organisations we often combine this with our Python or Node.js developers in a broader app build project.

KubernetesHelmPrometheusGrafanaDatadog

What you get at the end.

Not just an engineer for the duration of the project, but infrastructure that can keep running on its own, manageable by your own team or a successor.

IaC codebase

Infrastructure in Terraform or Pulumi, in your own Git repository, with state held in a remote backend that you manage.

Pipeline as code

All CI/CD flows as code in your repository, with secrets held in a vault. No one-off configurations in a UI.

Runbook and on-call

Incident response procedures, alert routing, a post-mortem template, and an on-call rota your team can take over.

Architecture document

A document that explains the choices (why EKS rather than ECS, why Loki rather than Elasticsearch), useful for onboarding.

Option for ongoing management

Ongoing platform management, security patches, cost monitoring and minor further development through our application management service.

Three ways of working, choose what suits you.

How you bring in a DevOps developer depends on what your team can handle itself and how large the scope is.

Engagement model 01

Dedicated DevOps engineer

Our DevOps engineer works full-time on your project, integrating with your stand-ups, sprint rituals and product owner, while staying connected to our team for reviews, sparring and knowledge sharing. You steer on output; we take care of continuity. Suitable when you don't yet have in-house DevOps capacity, or need temporary extra firepower for a large migration or platform build.

Engagement model 02

DevOps consultant

When you mainly need advice and an initial setup (strategy, platform choice, the first IaC foundation, the first pipelines) and then want your own team to take the work forward. Our consultant delivers an advisory document, the setup and a knowledge handover, with an open end for follow-up whenever you run into issues. For the top search query "hire a DevOps consultant", this is exactly what we provide.

Engagement model 03

Team augmentation

Your own developers lead the project; our DevOps specialist works alongside them on the areas where your team has less experience, such as Kubernetes internals, a complex cloud migration or a service mesh implementation. We work in your repository, with your rituals and your tooling, and build up the knowledge so your team can carry it on its own afterwards.

Engagement model 04

Senior lead or platform architect

A senior DevOps engineer or platform architect who also thinks at the strategic level: cloud strategy, cost model, governance, a security baseline and the platform roadmap. Suitable for organisations moving from loose cloud resources to a structured platform, or where an earlier freelance arrangement has left infrastructure that nobody dares touch any more. We bring structure without rewriting the whole platform.

How an engagement works.

01Introduction→ 02Audit & match→ 03Build→ 04Handover

Introduction

A short session to sharpen the scope, your current cloud setup and your preferred way of working. We share examples of previous work and discuss the seniority level you need.

Audit & engineer match

We carry out a brief review of your current pipelines and infrastructure, and assign a DevOps engineer to your project based on your cloud mix. You speak with the engineer beforehand yourself.

Sprints with reviews

Sprints with demo and review. Every infrastructure change or pipeline adjustment undergoes peer review by a second senior engineer: no pull request reaches main without four eyes on it.

Handover

At the end of the engagement, a structured handover to your own team or a successor, with a runbook, an architecture document and live walkthrough sessions.

Stack expertise from our DevOps team.

We work at mid-level to senior-lead level. No junior-only staffing: every engagement has at least a senior behind the review. The stack mix you choose depends on your project and existing cloud choice; the pills below are what we build with in practice.

CI/CD & automation
GitHub ActionsGitLab CIJenkinsCircleCIArgoCDFlux
IaC & cloud
TerraformPulumiOpenTofuCloudFormationAWSGCPAzure
Containers & observability
DockerKubernetesHelmIstioPrometheusGrafanaLokiDatadogNew Relic

When DevOps, SRE or platform engineering.

In practice these roles overlap. We cover all three and choose based on what your situation requires; the breakdown below will help you decide.

Discipline 01

DevOps engineer

Focused on CI/CD, build and deployment automation, infrastructure as code and the pipeline from git commit to production. Often the first role teams hire when release frequency needs to rise and manual steps need to go. We provide this role as a dedicated resource or as team augmentation.

Discipline 02

Site reliability engineer

Focused on reliability, SLOs, on-call, incident response and post-mortems. An SRE usually comes into the picture once a platform is already running and must stay up, and the business is complaining about outages or slow response times. We build SRE practices into our engagements as standard, so mid-market organisations do not need a separate role.

Discipline 03

Platform engineer

Focused on developer experience: building an internal platform-as-a-product that your own developers can use to roll out services without DevOps help. Often built with Backstage, Crossplane or a custom abstraction. Suits growing organisations (10+ developers) where the DevOps bottleneck is becoming visible.

Discipline 04

Cloud architect

Focused on high-level cloud strategy: multi-region setups, cost modelling, vendor selection, governance and compliance. Often a shorter advisory engagement than a dedicated engineering role. Suitable when you are still early on the cloud learning curve or are considering a major migration.

In practice

Overlap is the norm

Most of our DevOps engineers touch all four disciplines within an engagement. What you need depends on your team size, cloud maturity and specific pain points. Tell us what you are looking for in an initial conversation and we will match on what fits, not on job titles.

When a permanent hire rather than a consultant

A permanent DevOps hire

For organisations with daily production operations and a growing cloud footprint, hiring a permanent DevOps engineer usually delivers more value than an ongoing consultant. We often help with the initial setup, a working baseline and knowledge transfer to your first in-house hire, after which we can remain on call for advice or peak periods.

Why a team DevOps over a standalone freelancer.

For a short-term project with limited scope and low risk, a freelance DevOps engineer is fine. For anything that touches production, integrates with other systems or runs longer than a few sprints, we advise against it. The reasons are not abstract: we see them come back every month when a new client calls us in to clean up a freelancer's legacy.

Peer review on every infrastructure change. Every Terraform pull request or pipeline change goes through review by a second senior engineer. A freelancer reviews their own work or, at best, a developer on your team who knows just enough cloud to click "approve". The difference in reliability and cost control after six months is substantial.

Replaceable within the team. When our engineer is ill or moves on to another assignment, they actively hand over to a colleague who already knows the codebase from reviews. With a freelancer, "two weeks' holiday" means "no deployments possible", or worse, a second freelancer who has to reinvent everything.

Contractual certainty. You contract with Appfront B.V., not with an individual. That means IP rights are properly arranged, NDAs are enforceable, ownership of pipelines and infrastructure as code rests with you contractually, and there is a liable party when something goes wrong. For projects involving production data or customer data, that is not a luxury.

Transferable infrastructure. We know the engagement will eventually end, so the infrastructure is set up with that handover in mind. Everything in code, all keys in a vault, all accounts at organisation level, no personal SSH keys in production. When the contract ends, nothing changes about who can do what; you run the platform independently straight away. For ongoing management we often combine this with our enterprise software service or a defined application management contract.

Frequently asked questions.

What is the difference between a DevOps engineer, an SRE and a platform engineer?
In theory these are three distinct roles: DevOps focuses on the delivery pipeline and automation, SRE on reliability and on-call, and platform engineering on developer experience and an internal platform as a product. In practice they overlap considerably at mid-market organisations. Our engineers work across all three disciplines. Tell us about your pain points in a first conversation and we will match you based on content, not job title.
Do you work with a Dutch team or an EU team?
The DevOps team works from the Netherlands in the Dutch time zone. Communication can be in Dutch or English, whichever you prefer. No offshore handover, no handover cycle of half a working day during a production incident, no language barriers in code review or stand-ups. For incidents during office hours, you are not waiting on a ticket queue in another time zone.
Contract: fixed or flexible?
Both. For dedicated engineers and team augmentation we work with an hourly rate and a minimum weekly commitment, cancellable monthly. For consultancy engagements involving scoping and advice we often agree a fixed-price contract based on deliverables. No long lock-ins and no mandatory minimum contract term measured in years.
What happens if the DevOps engineer leaves halfway through?
That is exactly why we work with peer review and team backup. When someone on our team drops out or moves on, the second senior is already familiar with the codebase through earlier reviews and can take over after a short handover. You are not left at a standstill. With a standalone freelancer in the same situation, you would be; we see that come back every month in takeover projects.
How is knowledge handed over at the end?
A standard part of every engagement: a runbook with operational instructions, an architecture document explaining choices and trade-offs, and walkthrough sessions with your own team or successor. Preferably in the final sprints of the engagement, not on the very last day, otherwise questions always remain that only our engineer can answer.
Do you help choose between AWS, GCP and Azure?
Yes. We have production experience with all three. The choice rarely comes down to technical features, which have largely converged, and far more often to your existing contracts, audit requirements, regional constraints and which cloud your own team already knows. We give honest advice, even when that means you stay with your current cloud and we don't need to carry out a migration.
Do you also do migrations from on-premises to cloud, or between clouds?
Yes. A considerable part of our engagements is migration work: from on-premises to AWS or GCP, from a legacy PaaS to Kubernetes, or cross-cloud when a vendor choice no longer fits. We work in phases with a rollback plan at every stage, rather than a big-bang cutover. This is often combined with a broader legacy replacement project.
How is pricing determined?
For team augmentation and a dedicated engineer, we charge an hourly rate depending on seniority (mid-level, senior, senior-lead). For consultancy and project-based scope, we charge per sprint or a fixed total budget based on deliverables. We share rates openly during the introductory call, with no hidden tiers or penalty clauses. We give budget indications verbally based on your scope, not via a pricing page, because that rarely reflects what an engagement actually requires.
Do you also build an internal developer platform (IDP)?
Yes, often based on Backstage or a custom abstraction over Kubernetes and cloud resources. It usually suits organisations of 10+ developers where the DevOps bottleneck is becoming visible, as manual service onboarding then takes too much time. We build a minimal IDP with a few self-service flows and expand based on what your own developers actually use.

Talk to us about your DevOps project.

A no-obligation introductory conversation of half an hour. We listen to your cloud setup, ask follow-up questions where needed, and are honest about whether a DevOps engineer is the right step here, or whether a shorter consultancy engagement will suffice. No sales pitch.

Edit content