Forward Deployed Engineer - Mainloop

Leyton; Barcelona; Presencial; EUR 90.000 - 150.000; Jornada completa

Descripción de la vacante

Leyton's Mainloop Barcelona team is hiring a Forward Deployed Engineer to go into client operations, map processes, build fast demos and hand over to Product Owner and engineers. You travel to different countries, sit with the workers, understand the real workflow, and define the architecture from a business-process perspective.

You will use AI agents to accelerate delivery, produce MVPs in two weeks, and ensure handover.

Descripción del empleo

Forward Deployed Engineer

Go into a business that has never been automated, work out how it actually runs, and have something working in front of them in two weeks. Then hand it over properly, and go and do it somewhere else.

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 administration. That is the material: the admin. The forms, the approvals, the reconciliations, the eleven‑day handoffs, the spreadsheet somebody rebuilds every month. We work in two halves. One half — this half — goes into a business, finds out what really happens there, and builds something fast enough to prove whether it is worth having.

The other half takes what we prove and turns it into something the company depends on.

Most automation teams only have the first half, which is why they end up with a drawer full of demos. Most of the rest only have the second half, which is why they build what somebody remembered to ask for. We are hiring the people for the first half.

We are not only looking for a developer. We are looking for someone with a consultant's instincts who can build — someone who is more interested in why the invoice takes eleven days than in which framework we use, and who can then go and build the thing that fixes it.

What the job actually is

A project arrives. It is usually a sentence — our people spend two days a month reconciling this by hand. — From there it is yours.

• You go there. In person, to whichever country it is, and you sit with the people who actually do the work. Not the manager's description of the work — the work.
• You understand the process properly. How it really runs, who touches it, where it hurts, and what it costs today. It is almost always administrative work — that is where the time goes in a professional‑services business, and it is where we win. How long it takes is set by the process, not by a calendar. Something simple is days. Something genuinely complex is weeks before anything gets built, and saying so is part of the job — we would much rather hear "this is more tangled than it looked" in week one than in week six.
• You check what we already have — before you build anything. This is a real step, not a courtesy. We own a portfolio, and a serious part of doing this job well is knowing it well enough that when a business describes their problem you already know we have most of it. Sometimes the answer is we have this, it just needs configuring. More often it is most of this exists over there — and you take that code and cut a PoC out of exactly the part you need. You will not be doing that from memory alone: you get code intelligence across the whole estate, wired into an agent you can hand a spec to and ask what of ours already does this?
• You write the functional architecture. How the thing works — the flow, the actors, the rules, the data that moves and the decisions in the middle. Functional first: this is a business‑process job, not a systems‑design one. You will make technical calls and you need to be able to, but the deep technical architecture is not what you are for, and the parts that need one go to Edouard and the Tech Lab. This document is what the agents build from, which makes writing it precisely the highest‑leverage hour of your week.
• You build it. Agentic build, steered by you: idea to something showable in one to two weeks once you understand the process.
• You put it in front of people, repeatedly. A short series of increasingly real prototypes, each shown to the stakeholders, each one better because of what came back. You own that loop and the first testing.
• You say whether it is worth it. You have been sizing the benefit since day one, so when the answer is no, you can say it with numbers.
• You get it to MVP, and you get people actually using it. Onboarding the users and following up afterwards is yours, not somebody else's afterthought.
• You write the handover pack while you build, hand the whole thing to a Product Owner and an engineer, and move to the next one.

Then you do it again, somewhere else, on something completely different.

The line you stop at — and why it is in your favour

You take a project to MVP. Not to production, and not for years. Once it is proven and near‑ready, our Tech Lab takes over: hardening, scale, security, the long run. You are out — properly out, not "available for questions".

That line is deliberate and it is the best thing about this job. You never accumulate a tail. You are not the person still being called in fourteen months about a thing you built in an afternoon, you are not maintaining six half‑owned prototypes while trying to start a seventh, and you do not slowly become the support desk for your own back catalogue. That is how this role burns people out everywhere else it exists, and it is the specific failure we built a second team to prevent.

Occasionally you will stay a little longer, and it will be because it is faster. If the follow‑up after launch is going well and the Product Owner is not free yet, you may keep running it for a while rather than let the thing lose momentum — a choice we make deliberately, in the open, and always with an engineer already on the other side. What we do not do is leave you quietly holding it.

What you get instead is the part most engineers say they want and rarely get: a new problem, a new business and a blank page every few weeks, with someone competent to hand the finished thing to.

An honest "no" is a real result here

Some of what you look at will not be worth automating. When that is true, you stop, you write up why, and that counts as a delivered outcome — because the next person does not repeat the work, and the business gets an answer instead of a project.

This only works if somebody has been quantifying the benefit from the first conversation, and that somebody is you. It is also why we mean it: you will have the standing to kill your own project, which is not a sentence most companies can write honestly.

You will get seriously good at building with AI agents

We are an AI‑native team, genuinely — not a team that added a Copilot licence. Everyone gets their own Claude Max subscription and a desktop orchestrator that runs several coding agents in parallel. You will learn to drive that properly: how to get speed and quality at the same time, where it fails, and how to look at what came out and tell whether it is actually right.

Which changes what the work feels like. Very little of your week is typing implementation. Most of it is the things that decide whether software is any good — what should exist, what shape it should be, what the business will actually adopt — and then dropping into the detail exactly where the detail matters. You do not need to be able to hand‑write production code; you need to be able to specify precisely, steer well and judge what comes back. We will train you on our architecture, our patterns and our pipeline. That part is on us.

"If the agents build it, what am I for?"

A fair question to ask of an ad like this one, so here is the honest answer: the agents are the fastest part of the team and the least trustworthy one, and we do not expect that to change. Everything that decides whether the project was worth doing runs through a person.

What stays yours, permanently:

• Finding out what actually happens. Nobody has written it down. The person doing the job will describe the version in the procedure, not the one with the three workarounds in it — and the workarounds are the project. Noticing that gap takes a human in a room.
• Deciding what not to build. Half of doing this well is reuse, scope and refusal. An agent will cheerfully build the thing nobody needed.
• Sizing the benefit, and being willing to say no. Numbers, and the nerve to put them in front of the person who asked for the project.
• Turning it into a specification precise enough to be built. An agent will build exactly what you specified, beautifully, even when what you specified was the wrong shape. Getting from "they need this" to a spec that produces the right thing is the hardest hour of your week and the one nothing automates.
• Everything human. Being trusted by people who did not ask for you to turn up. Telling a stakeholder their favourite idea is not worth it. Handing over so well that the people inheriting it never need you.

Our position, plainly: we are AI‑native because it lets a small team do far more than its size, not because we think people are the expendable part. We hire fewer, better people and give each of them much more leverage — the opposite of hiring fewer because we need them less.

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 read a business process, and how to take something from a conversation to a working product a company depends on. 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 go into a business and build production‑grade software with AI agents, not just prompt their way to a demo. 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 are moving countries or changing track 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 that the market is currently repricing upward — and leaving with something you can show for it. The entry‑level work that is disappearing everywhere right now is the work these agents do. This is the job on the other side of that.

How we build

Every project starts from the same scaffold, and it is the same in most of our repos — deliberately. For you that is the whole point: you start something new every few weeks, and none of those weeks should go on re‑deciding the same five questions. It also means the team you hand to can pick your project up without a translation layer, and that the code you found in one of our products can be cut into a prototype for another.

You do not need to arrive knowing our tooling. You do need to be comfortable enough across the front and back of a web application to steer a build and know when something is wrong. The rest — our architecture, our patterns, our pipeline— is what we train you on, and it is a large part of what the certificate is for.

Things worth knowing up front

• You will travel a lot, and we are saying so plainly. Barcelona is your base and where the team sits, but the businesses are spread across roughly fifteen countries and you go to them. Sometimes that is a few days. Sometimes it is a few weeks in one place, because a process you cannot see is a process you will get wrong. Being in the room is the method here — it is not an occasional extra on top of a desk job, and if that is not the life you want, this is the wrong role and we would both rather know now.
• Travel and accommodation are on us, and we care about the difference between a bed and somewhere you can actually live when the stay is a long one. Ask us about it — we would rather talk about how we handle a three‑week deployment than have you find out.
• Nobody is on call. Ever. No rota, no pager, no phone number. Alerts post to a channel and wait. We protect against 3am with engineering — infrastructure as code, tested restores, one‑click rollback — not with people's evenings.
• You are not a consultant selling days. Nobody counts your hours. What gets looked at is whether the thing worked, whether it got used, and whether the handover held.
• We are building the team this year, and you will shape how it works. Some of our processes are written and 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 do not expect you to absorb the cost of relocating, and we would rather say what we cover than leave you to ask.

• 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:

• 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.
• Nobody is on call. Ever. No rota, no pager, no phone number. Alerts post to a channel and wait.

And the travel reads differently depending on where you are standing.

Everything above is true and we are not softening it — this is a lot of time away from home. But if part of why you are still reading is that you would rather work across Europe than read about it: this job takes you to fifteen countries, pays for all of it, and gives you somewhere to come back to.

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: your entire salary here would 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 get one — but ask in the first conversation and we will walk you through the comparison we ran, including the parts where the number comes out smaller.

What we are looking for

One bar sits above everything else on this list, so here it is plainly. We do not require that you are the expert coder — for the code, you have AI agents. We do require that you can architect the project: understand the need, be genuinely up to date with what the technology can do, know the infrastructure you are building on — and then implement it and carry it from zero to MVP, where you hand it to a Product Owner and an engineer. If you read that and thought "that is the job I want" keep reading.

Read the rest as a description of the person you will be here, not a checklist you have to arrive with. Almost nobody ticks all of it on day one, and we would rather hire the instinct and train the rest — which is a large part of what the certificate is for. If several of these are true of you and the others sound like things you want to get good at, apply.

• You are interested in how businesses actually work. Processes, the mess in them, and why people do the odd thing they do. This one is not trainable and everything else here is.
• You can build. Comfortable across the front and back of a web application. Which language you have been using matters far less to us than whether you can get from an idea to a working thing on your own.
• You reach for what already exists before you write anything. The engineers we do not want are the ones for whom every problem is a new repo. Ours is a portfolio job: knowing what we have, and being pleased rather than disappointed when the answer is we have already built most of this.
• You use coding agents seriously, and you read what they produce the way you would read a colleague's work.
• You can walk into a room of people who did not ask for you to be there and come out with the truth. Asking the question that gets the real answer is most of stage one.
• You write well. The architecture, the writeup when the answer is no, and the handover pack are all documents, and all three are read by people who were not in the room.
• You can let go. When it is handed over, it is not yours any more. Some very good people find this genuinely hard, and it is worth knowing that about yourself before you apply.
• English, fluently. It is our working language — we work across roughly fifteen countries. Spanish is genuinely useful day to day. Catalan is not required.
• Barcelona, with travel.

We do not care what you studied. We care what you have built, what you understood about the business you built it for, and whether you can talk us through the decisions in it.

How we hire

Our process is unusual, so here it is up front. Four rounds, and none of them is a puzzle.

• Fifteen minutes with Edouard. A short first conversation — who you are, what you are after, and what this actually is. Enough for both of us to work out whether the next one is worth an hour.
• A thirty‑minute conversation. What you have built, how you work, and how you think about it. We will ask you to walk us through something you built and then to justify a specific decision inside it. There is no way to prepare for that and it is not meant to catch you out; it is how we tell understanding from familiarity.
• A conversation with our Casablanca team. The group has run a tech lab there for more than eight years. You get people who have run production at real scale asking their own questions — and you get to ask them yours, including the ones you would rather not ask the person hiring you.
• A project. We give you a brief and a working environment to build it in, with Claude Code already set up and wired to a key, so you are building the way we actually build rather than talking about it at a whiteboard. It is real work rather than a puzzle, you do it on your own schedule — no week off, no flights, nothing that requires you to already be free — and we go through what you built together afterwards.

Interrested in a Hackthon

We are hosting a Hackathon between the 9-16th of October. Anyone is free to join !

You will have the chance to win prizes and move straight to the final round of interviews !!

How We Started

Leyton remains first and foremost an entrepreneurial adventure, which began with the perseverance of two determined characters: François Gouilliard co-founder and chairman, and Olivier de Beauminy, Co-founder.