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 that are drowning in process. We work in two halves. One half goes into a business, works out what actually happens there, and proves fast whether an idea is worth having. The other half — this half — takes what is proven and owns it for years.

This is the seat where the product and the engineering are the same job. Most of our products are run by a pair: a Product Owner who holds the business, and an engineer who holds the build. Some of them do not need two people. They are smaller, their users sit close enough to talk to directly, and a separate PO would be a relay rather than a help. Those products are run by one person, and that person is you.

What the job actually is

You own a product end to end. Not a slice of it, and not the tickets someone else wrote about it. You decide what it should do next, you build it, you ship it, and you find out whether it worked.

• You talk to the people who use it. In person when you can. You read the feedback, you watch how the product is really used, and you notice the workaround nobody thought to mention — because the workaround is usually the next feature.

• You decide what comes next. There is no one above you writing the roadmap for your product and no one below you writing the stories. You choose what moves the outcome, what waits, and what you decline — with a reason the person asking can respect.

• You build it, front to back. The interface, the logic underneath, the data it keeps. You decide whether a feature makes sense on the screen and whether it holds up behind it, which is exactly the judgement that gets lost when those two calls belong to different people.

• You ship it and you measure it. A feature is not done when it merges; it is done when people use it and the number moves. You own that number — time saved, errors avoided, uptake — and you report it whether it flatters us or not.

• You carry more than one. Our products are built on the same scaffold and arrive the same shape, so one person can own several small ones well. New ones keep arriving from the other half of the team.

How this differs from the Full-Stack Engineer seat

Both seats sit in the Tech Lab, both build with agents, and both own products for years. The difference is where the product decisions live. A Full-Stack Engineer works beside a Product Owner, who holds the business relationship and the roadmap, and owns the build, the architecture and the release. A Full-Stack Product Engineer holds both halves — on products small enough, and close enough to their users, that splitting them would only slow the product down.

If you want to go deep on architecture and let someone else hold the room, the Full-Stack Engineer ad is the better fit. If you care as much about whether a feature should exist as about how to build it, this one is.

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. Every engineer gets their own Claude Max subscription and a desktop orchestrator that runs several coding agents in parallel. In this seat that changes the arithmetic of the job: when building is fast, the expensive part is deciding — and you are the person who does both.

• Every change is reviewed by an agent before a person signs it off.

• Every build ships tests, and the gate is 100% pass. Unit, smoke against the real running thing, and browser-level end-to-end.

• Anything AI-powered ships with evals — a scored set of inputs, not "it looked right when I tried it".

"If agents write the code, what am I for?"

The agents will build anything, quickly and confidently — including the wrong thing. In this seat the risk is not slow software, it is fast software nobody needed. What stays yours, permanently:

• Finding out what people actually need. Users describe what they ask for, not what would help. Reading the difference takes a person who has watched them work.

• Deciding what not to build. Somebody has to be the person for whom "no" is a complete sentence with a reason attached.

• Turning a need into a specification that is actually right. An agent builds exactly what you specify, beautifully, even when what you specified was the wrong shape.

• Judging the output. Agent code compiles, passes the test it wrote for itself, and is subtly wrong in ways only someone who understands the product will catch.

• Accountability. When something breaks, a person decides whether to roll back and a person tells the users. Here, that is you.

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 production software with AI agents to a standard, 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.

Things worth knowing up front

• Nobody is on call. Ever. No rota, no pager, no phone number. Alerts post to a team channel and wait. If something breaks at 3am on a Saturday it is fixed on Monday morning — deliberately. We protect against that with engineering, not with people's evenings: infrastructure as code, restores we have actually tested, one-click rollback.

• You own your products' incidents during working hours. Support is not shipped off to a separate team; it is part of owning the thing, and it keeps you honest about quality.

• You will spend real time with users, not only with code. If a week of conversations, screen-shares and feedback sounds like a distraction from the real work, this is the wrong seat — here that is the real work, alongside the building.

• 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 have ever wanted a say in how an engineering team actually operates, this is the window.

What we are looking for

Read this as a description of the person you will be here, not a checklist you have to arrive with. If several of these are true of you and the others sound like things you want to get good at, apply.

• You have shipped something people used, and you watched them use it. At a company, at university or on your own — what matters is that you made the product calls, saw what happened, and changed course.

• You are comfortable across the front and the back of a web application. Strong TypeScript if you have it; if your language has been something else and you are good, say so.

• You have taste in interfaces. You can tell when a screen is making the user do the system's work, and you fix it without waiting for a designer.

• You can talk to people who are not engineers and come back with what they need rather than what they said.

• You use coding agents in your work and you read their output like you would a colleague's.

• You write clearly. Specs, release notes and the occasional "we are not building this, and here is why" are all documents someone else has to act on.

• 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. This is a team that sits together, especially in its first year.

We do not care what you studied. We care what you have built, who used it, 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.

1. 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.

2. A thirty-minute conversation. We will ask you to walk us through something you shipped and then to justify a product decision inside it — what you built, what you chose not to, and how you knew whether it worked. It is not meant to catch you out; it is how we tell product judgement from familiarity.

3. 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.

4. A project. We give you a short brief, written the way a user would actually describe the problem, and a working environment with Claude Code already set up. You decide what to build, build it, and tell us what you left out and why. You do it on your own schedule, and we go through it together afterwards.

Mainloop · Barcelona. Apply with something you have shipped and a paragraph on a feature you decided not to build.