Senior DevOps Engineer - Mainloop

Senior DevOps Engineer

Build a company's entire delivery platform from the first commit, own it outright, and never carry a pager. Both halves of that sentence are deliberate.

This is a senior role and it is not a role we can hire junior into — you are the first, for a while the only, and the platform everyone else builds on is the one you put in place.

Mainloop is a new engineering team inside an established international group. We are in Barcelona, we are being built from scratch this year, and we have the backing, the customers and the product portfolio of a company that has been around for decades. You get the interesting part of a new team without the part where you check whether payroll clears.

Two more things about where this comes from and where it goes. The group has been running a tech lab in Casablanca for more than eight years — Barcelona is its second, built to sit closer to the teams we build for, and AI-native from the first commit, because it starts from a blank page. And the plan does not stop at internal work: within about a year and a half we intend to externalise — external clients, our products sold on the market, products developed for it. The first eighteen months are deliberately spent building as much as possible for the group while the machine gets set up. You would arrive at the start of that curve, not after it.

What we build is the software that automates professional-services work — across roughly fifteen countries, for businesses drowning in process. We build those products and we run them. That second half is why this role exists, and it is not a formality: a team that owns how its software is built should own how it ships.

You are the person who ends that. You are our first DevOps engineer, and for a while our only one.

What the job actually is

You are not inheriting a platform. You are writing one.

There is no infrastructure-as-code in our estate today — not a line. The environments that exist were built by hand and are reconstructible only from a runbook and one person's memory. Your first job is to make that permanently untrue: every environment we run reproducible from a committed repo, from your first week, before the habit sets.

In Your First Few Months You Will

• Build the platform from code. Hosts, networking, ingress, access, environments — committed, parameterised, reviewable. It is the cheapest moment this will ever be done, and you get to do it properly instead of retrofitting it.
• Make deployment self-serve. Today, shipping an existing app is a git push; standing up a new one needs admin rights and two undocumented footguns. That gap is yours to close, down to one command, so a developer never holds a platform credential.
• Own secrets properly. A real machine secrets manager, and — because we run a lot of AI agents — credentials brokered so an agent process only ever holds a placeholder, never a key. If you have opinions about how you stop a prompt-injected agent leaking a production credential, you will enjoy this part; almost nobody gets to design it from scratch.
• Prove the restore. We have a written standard that says "someone deploys it" is not "someone has proven the restore works." You will run the drill, write the report, and be the reason the honest answer to "is it backed up?" changes from no to yes, and here is the evidence.
• Build the release path. Commit to production, an automated test gate, per-branch preview URLs a stakeholder can open from their phone, and a rollback that everyone on the team has rehearsed before they need it.
• Then keep it all running — and keep making it duller. Observability, cost caps, dependency hygiene, the unglamorous work that decides whether a small team can own a lot of products.

And you will have the authority to match. You are not implementing someone else's platform design. You report directly to Edouard, there is no layer in between, and how this is built is yours to decide. We are hiring at senior level precisely so that those decisions can be yours — the platform every product here runs on is the one you put in place, and we would rather bring in the judgement than supervise it.

Nobody is on call. Ever.

No rota, no pager, no phone number, no "just keep an eye on it this weekend". Alerts post to a team channel and wait there. If something breaks at 3am on a Saturday, or in the second week of August, it gets fixed the next working morning. This is a decision on the record, not an oversight we will rediscover later — and it applies to every product we own, with no exceptions.

We are telling you this up front because it is not a perk we are quietly hoping you will waive. Plenty of ads say "healthy on-call culture" and mean a rota. We mean there is no rota.

Here is the honest other half, and it is the actual job: we can only make that promise because we protect ourselves with engineering instead of with people's evenings — and that engineering is what we are hiring you to build. Infrastructure as code, so a lost machine is rebuilt rather than resurrected. Backups with a restore we have actually tested. A rollback that is one click and that everyone has already practised. Alerting that queues instead of paging, because nothing on the other end of it is expected to answer at night.

So the trade is explicit: you are never woken up, and in exchange the systems have to be genuinely recoverable. If you have spent a career being paged for things that should have been engineered away, this is the version of the job where you get to do the engineering instead.

During working hours it is the opposite of hands‑off. The PO, the developers and the DevOps engineer assigned to a product own that product's incidents — support is not shipped off to a separate team, it is part of owning the thing, and it is what keeps everyone honest about quality.

How we build — deliberately boring, and you get a say in it

We have a settled stack and it is the same in most repos on purpose: one scaffold, shared packages, push-to-deploy. The payoff is that a two-person team can pick up a product they have never seen and be useful the same day, which is the only reason a team this size can own this many products.

We build the simplest platform that meets the requirement, and we are strict about what the requirement actually is. Complexity here has to earn its place: every capability we run is one more thing one team has to understand, patch and be able to rebuild.

A concrete example, because it tells you a lot about us: we do not run Kubernetes, and that was a decision rather than an omission. We looked at it properly, twice — most recently because we were worried we had got it wrong — and both times the answer was that a small portfolio on predictable traffic does not need multi-node scheduling and autoscaling badly enough to pay for them with the only infrastructure engineer we have. We wrote down the specific conditions under which we would change our minds, and when one of them is met, we will.

Which is why we are asking for someone who has run Kubernetes in production and can tell us when it is not the answer. If your idea of a good week is tuning a cluster, this is the wrong job and we would rather you knew now. If your idea of a good platform is one a small team can fully understand, rebuild from a repo and hand to a new joiner in an afternoon — and you have enough scar tissue to know where that stops being enough — that judgement is most of what we are hiring.

It is a default, not a straitjacket. Some things genuinely need something else, and when they do we adapt deliberately, with the reasoning written down. What we do not do is re-decide the same five questions on every new repo out of habit.

And you get a say in what the standard is. Anyone can propose a change — something new that is genuinely better, something we should upgrade to, something we got wrong. A proposal gets researched properly against the alternatives, it gets an answer, and if the answer is no you get the reasoning. On infrastructure, you are not one voice among many — you are the one who decides, within a budget you help set.

You will get seriously good at building with AI agents

We are an AI-native engineering team, genuinely — not a team that added a Copilot licence. Every engineer gets their own Claude Max subscription and a desktop orchestrator that runs several coding agents in parallel, each in its own branch. That is true of you too: a great deal of infrastructure work is now specified rather than typed, and you will get very good at driving that — where it works, where it fails, and how to read a diff and decide whether it is actually right.

It Also Makes Your Job More Interesting Than The Same Title Elsewhere, Because Agentic Engineering Creates Infrastructure Problems Most Teams Do Not Have Yet

• Agents install packages into code that sits next to client data. Supply‑chain hygiene stops being a compliance checkbox and becomes a live control you own.
• Agents hold credentials — or rather, they must not. Brokering machine identity so the agent never touches the real key is a design problem, and it is yours.
• Agents cost money in a way that is invisible until the invoice. Per‑project budgets, hard caps and an alert that fires before the cap, not after it.
• Agents can deploy. Which means the guardrails between "an agent proposed this" and "this is in production" are infrastructure, not policy.

If you have been running agents seriously and have opinions about where they break, we want to hear them. If you are curious but not yet deep in it, that is fine — teaching this well is something we intend to be known for.

The Mainloop Barcelona certificate

Something we are building alongside the team, and we think it is genuinely unusual.

Over your first two to three years here you work through a defined body of knowledge — our architecture, the agentic build method, how to take a product from an idea to something a business depends on, and how to run it well. When you have covered it and can demonstrably run a project our way, you are awarded the Mainloop Barcelona certificate.

It is yours. It goes on your CV, and we intend to make it mean something in this market — a signal that the person holding it knows how to build and run production software with AI agents to a standard. We are investing in making it prestigious, because a team whose alumni are sought after is a team good people want to join.

If you would be moving countries to take this job, this is the part to weigh most carefully. You would not only be taking a role; you would be spending two or three years acquiring a way of building and running systems that the market is currently repricing upward — and leaving with something you can show for it, on top of a platform you can point at and say you built.

Things worth knowing up front

• This is an on‑site role in Barcelona. More than the other seats here, and for a real reason: you are standing up physical‑ish infrastructure and access for a team being assembled around you, in its first year, and most of that goes faster in a room.
• You are the only DevOps engineer for a while. That is authority, and it is also a bus factor — which is why "nothing exists only in one person's head" is written into the role rather than hoped for. Everything you build gets documented and reproducible as you go, not afterwards.
• We are building the team this year, and you will shape how it works. Some of our processes are written, some are not, and the ones written after you arrive will have your fingerprints on them.

If you would be moving to Barcelona for this

• We pay to get you here. Flights, your first month's accommodation while you find somewhere of your own, the visa and paperwork costs, and an agent to handle the bureaucracy — the NIE, the TIE appointment, the apostilles — instead of leaving you to meet the Spanish administrative system alone. Spanish lessons if you want them.
• A relocation bonus, paid on arrival rather than dripped out. It is repayable only if you leave within the first eighteen months, and that condition is the reason we can pay it up front — moving countries costs money at the start, not in year two.

Three things here are worth more than they look on an offer comparison, particularly against a US one:

• Nobody is on call. Ever. It has its own section above and we mean it literally. If you are coming from a market where infrastructure work and a pager are assumed to travel together, read that section twice — it's the single largest difference between this job and the same title elsewhere, and it is not a perk we are quietly hoping you will waive.
• Healthcare with no premium, no deductible and no network — from day one, and not tied to staying in this job.
• Thirty calendar days of holiday — that is 22 working days — plus fourteen public holidays, roughly seven weeks in total. That is the statutory floor in Spain, not a benefit we are being generous with.

And the on‑site line reads differently depending on where you are standing.

For someone already in Barcelona it is a constraint and we have said why. For someone moving here it is most of the point: this is a job in Barcelona, not a job you do from Barcelona — a team that sits together, in a city worth being physically present in.

If you are coming from the United States

two things are usually worth more than the headline salary gap and almost nobody has done the arithmetic: a salary here can sit below the Foreign Earned Income Exclusion, and federal student loans on an income‑driven plan are assessed on the income that exclusion has already removed. We are not your tax advisor and you should