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-deplo