Forward Deployed Engineer

Part 1

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.

• Barcelona
• travels
• Open
• 5 seats
• 1 lead, 4 junior

What you own

• 01 Understand the process, on site
• 02 Write the functional architecture
• 03 Drive the agentic build to a PoC
• 04 Run the stakeholder loop
• 05 Quantify the benefit — and say no when it is no
• 06 The handover pack

One method, many products

Mainloop is an engineering company in Barcelona. We own what we build and we answer to ourselves. You get the interesting part of a new company, with a real customer and real products from day one.

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 is knowing the portfolio 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 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