Hazte cargo de un producto de principio a fin —los usuarios, la hoja de ruta, el desarrollo y la release— sin nadie entre tú y las personas que lo usan.

- Los usuarios, en persona
- Qué se construye después, y por qué
- El desarrollo, de front a back
- Que de verdad se use

Mainloop es una empresa de ingeniería en Barcelona. Somos dueños de lo que construimos y respondemos ante nosotros mismos. Te llevas la parte interesante de una empresa nueva, con un cliente real y productos reales desde el primer día.

Lo que construimos es el software que automatiza el trabajo de los servicios profesionales, en unos quince países, para empresas que se ahogan en procesos. Trabajamos en dos mitades. Una entra en una empresa, averigua qué pasa allí de verdad y demuestra rápido si una idea merece la pena. La otra —esta— coge lo que está demostrado y se hace cargo de ello durante años.

Esta es la plaza en la que el producto y la ingeniería son el mismo trabajo. La mayoría de nuestros productos son lo bastante pequeños, y sus usuarios están lo bastante cerca como para hablar con ellos directamente, como para que repartir el producto y el desarrollo entre dos personas solo convirtiera a una de ellas en intermediaria. Así que los lleva una sola persona, y esa persona eres tú.

En qué consiste el trabajo de verdad

Te haces cargo de un producto de principio a fin. No de un trozo, ni de los tickets que otro escribió sobre él. Decides qué debe hacer después, lo construyes, lo sacas a producción y averiguas si funcionó.

- Hablas con las personas que lo usan. En persona cuando puedes. Lees el feedback, ves cómo se usa el producto de verdad y te fijas en el apaño que nadie pensó en mencionar, porque el apaño suele ser la siguiente funcionalidad.
- Decides qué viene después. No hay nadie por encima de ti escribiendo la hoja de ruta de tu producto ni nadie por debajo escribiendo las historias. Eliges qué mueve el resultado, qué espera y qué rechazas, con una razón que quien lo pide pueda respetar.
- Lo construyes, de front a back. La interfaz, la lógica que hay debajo, los datos que guarda. Decides si una funcionalidad tiene sentido en pantalla y si se sostiene por detrás, que es justo el criterio que se pierde cuando esas dos decisiones son de personas distintas.
- Lo sacas a producción y lo mides. Una funcionalidad no está terminada cuando se fusiona; está terminada cuando la gente la usa y el número se mueve. Ese número es tuyo —tiempo ahorrado, errores evitados, adopción— y lo reportas tanto si nos favorece como si no.
- Llevas más de uno. Nuestros productos se construyen sobre la misma base y llegan con la misma forma, así que una persona puede llevar bien varios pequeños. Siguen llegando nuevos desde la otra mitad del equipo.

Con quién trabajas, y qué plaza es la tuya

El Product Owner lleva los pocos productos lo bastante grandes como para que la relación con el negocio sea un trabajo en sí mismo, y ayuda en el resto. En todo lo demás, las decisiones de producto y el desarrollo son tuyos.

Tus productos vienen de los Forward Deployed Engineers,



que entran en una empresa, demuestran una idea en semanas y la entregan. Si prefieres empezar cosas a hacerte cargo de ellas, ese es tu anuncio. Si quieres ver un producto usado durante años y seguir mejorándolo, y te importa tanto si una funcionalidad debe existir como la forma de construirla, es este.

Vas a volverte muy bueno construyendo con agentes de IA

Somos un equipo nativo en IA, de verdad, no un equipo que añadió una licencia de Copilot. Cada ingeniero tiene su propia suscripción a Claude Max y un orquestador de escritorio que ejecuta varios agentes de código en paralelo. En esta plaza eso cambia las cuentas del trabajo: cuando construir es ágil, lo caro es decidir, y tú eres quien hace las dos cosas.

- Cada cambio lo revisa un agente antes de que una persona lo apruebe.
- Cada build incluye pruebas, y el listón es el 100 % superado. Unitarias, smoke contra lo que de verdad está en marcha y end-to-end en el navegador.
- Todo lo que lleva IA sale con evals: un conjunto de entradas puntuado, no «parecía que estaba bien cuando lo probé».

«Si los agentes escriben el código, ¿para qué estoy yo?»

Los agentes construyen cualquier cosa, rápido y con seguridad, incluida la equivocada. En esta plaza el riesgo no es el software lento, es el software rápido que nadie necesitaba. Lo que sigue siendo tuyo, para siempre:

- Averiguar qué necesita la gente de verdad. Los usuarios describen lo que piden, no lo que les ayudaría. Leer la diferencia exige a alguien que los haya visto trabajar.
- Decidir qué no construir. Alguien tiene que ser la persona para la que «no» es una frase completa con una razón detrás.
- Convertir una necesidad en una especificación que sea correcta. Un agente construye exactamente lo que especificas, y muy bien, incluso cuando lo que especificaste había la forma equivocada.
- Juzgar el resultado. El código de un agente compila, pasa la prueba que él mismo escribió y está mal de formas sutiles que solo detecta alguien que entiende el producto.
- La responsabilidad. Cuando algo se rompe, una persona decide si se hace rollback y una persona se lo cuenta a los usuarios. Aquí, esa persona eres tú.

Cosas que conviene saber desde el principio

- Las incidencias de tus productos en horario laboral son tuyas. El soporte no se manda a otro equipo; es parte de hacerte cargo del producto, y te mantiene honesto con la calidad.
- Vas a pasar tiempo de verdad con los usuarios, no solo con el código. Si una semana de conversaciones, pantallas compartidas y feedback te suena a distracción del trabajo de verdad, esta no es tu plaza: aquí eso es el trabajo de verdad, junto con construir.

Qué buscamos





Léelo como una descripción de la persona que serás aquí, no como una lista que tengas que cumplir al llegar. Si varias de estas cosas son ciertas en tu caso y las demás te suenan a cosas en las que quieres mejorar, preséntate.

- Has sacado algo que la gente usó, y la viste usarlo. En una empresa, en la universidad o por tu cuenta: lo que importa es que tomaste las decisiones de producto, viste qué pasaba y cambiaste de rumbo.
- Te mueves con soltura por el front y el back de una aplicación web. TypeScript sólido si lo tienes; si tu lenguaje ha sido otro y eres bueno, dilo.
- Tienes criterio con las interfaces. Sabes cuándo una pantalla le hace al usuario el trabajo del sistema, y lo arreglas sin esperar a un diseñador.
- Sabes hablar con gente que no es ingeniera y volver con lo que necesitan en lugar de con lo que dijeron.
- Usas agentes de código en tu trabajo y lees lo que producen como leerías el trabajo de un compañero.
- Escribes con claridad. Las especificaciones, las notas de versión y algún «esto no lo vamos a construir, y este es el motivo» son documentos sobre los que otra persona tiene que actuar.
- Inglés, con fluidez. Es nuestro idioma de trabajo: trabajamos en unos quince países. El español es muy útil en el día a día. El catalán no es necesario.
- Barcelona. Es un equipo que trabaja junto, sobre todo en su primer año.

No nos importa qué estudiaste. Nos importa qué has construido, quién lo usó y si puedes explicarnos las decisiones que hay dentro.

Cómo contratamos: las dos rondas pensadas para esta plaza

1. Una conversación de treinta minutos. Te pediremos que nos enseñes algo que hayas sacado y que justifiques una decisión de producto dentro de ello: qué construiste, qué decidiste no construir y cómo supiste si funcionó. No pretende pillarte; es como distinguimos el criterio de producto de la mera familiaridad.
2. Un proyecto. Te damos un enunciado breve, escrito como un usuario describiría de verdad el problema, y un entorno de trabajo con Claude Code ya configurado. Decides qué construir, lo construyes y nos cuentas qué dejaste fuera y por qué. Lo haces a tu ritmo, y después lo repasamos juntos.

El certificado Mainloop Barcelona

Durante tus dos o tres primeros años aquí recorres un cuerpo de conocimiento definido: nuestra arquitectura, el método de desarrollo agéntico, cómo leer un proceso de negocio y cómo llevar algo de una conversación a un producto en marcha del que una empresa depende. Cuando puedas demostrar que sabes llevar un proyecto a nuestra manera, se te concede el certificado.

- Nadie está de guardia. Nunca. Sin turnos, sin busca, sin número de teléfono. Las alertas se publican en un canal y esperan. Contra las tres de la mañana nos protegemos con ingeniería —infraestructura como código, restauraciones probadas, rollback en un clic—, no con las tardes de la gente.
- Estamos formando el equipo este año, y darás forma a cómo funciona. Algunos de nuestros procesos están escritos y otros no, y los que se escriban después de que llegues llevarán tus huellas.

#J-18808-Ljbffr

📌 Full-Stack Product Engineer (Barcelona)
🏢 Mainloop
📍 Barcelona