Forward Deployed Engineer - Mainloop

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 afte