El servicio como software necesita forward deployed engineers
Si vendes trabajo terminado, alguien tiene que hacerlo funcionar dentro de la empresa del cliente. Ese alguien es un forward deployed engineer, un ingeniero que se instala con el equipo del cliente. Es la parte más cara del modelo y la que decide si sale a cuenta.
Qué es un forward deployed engineer
El término viene de Palantir. Sus ingenieros de producto construyen una misma función para muchos clientes. Sus forward deployed engineers, a los que llama Deltas, hacen lo contrario: trabajan para un solo cliente y construyen todo lo que ese cliente necesita.
Trabajan con el equipo del cliente, aprenden cómo se hace de verdad el trabajo y hacen que el software lo haga. Palantir los mide por el resultado del cliente, no por el código que entregan.
No es un consultor. Un consultor recomienda. Un forward deployed engineer construye, lo pone en marcha y se queda hasta que funciona.
Por qué vender trabajo hecho exige a alguien dentro
Una herramienta se puede vender y dejar en una estantería. Hacerla funcionar es cosa del comprador. El trabajo terminado no se puede dejar en ningún sitio: si no llega, no hay nada que facturar.
Y el trabajo vive en los sistemas del cliente. Su CRM, sus hojas de cálculo, las excepciones que nadie escribió. Ningún modelo de IA las conoce hasta que alguien va y mira.
Por eso las empresas que venden agentes de IA contratan a estos ingenieros. En junio de 2025, a16z lo llamó el puesto más codiciado de las startups.
Dónde falla
En enero de 2026, Marc Andrusko, socio de a16z, dio la voz de alarma en «The Palantirization of everything».
Si copias solo a los ingenieros en el cliente, acabas con muchos desarrollos a medida que nadie puede mantener ni actualizar. En sus palabras, un «Accenture for X» con una fachada más bonita.
La mayoría de los problemas no justifican meses de ingeniería en el cliente. Y la gente que entiende a la vez el negocio y el código escasea.
Su consejo es tratarlos como un andamio: trabajo en el cliente con fecha de fin, un límite de personas y piezas que se puedan reutilizar.
Cómo lo aplico
Trabajo como un forward deployed engineer: dentro de tus sistemas, con tus datos reales y con tu equipo. Es como ya trabajo dentro de Sesame HR, donde cada equipo es un cliente interno. Con tres límites desde el primer día.
El trabajo en tu empresa tiene fin. El diagnóstico elige una tarea, y la construcción termina cuando el sistema cumple el criterio acordado. Después lo mantengo, sin construir más.
Lo que no es específico de tu empresa se construye para reutilizarse: las revisiones y el informe mensual. Solo lo que es de verdad tuyo se hace a medida.
El coste de cada tarea se mide desde el primer día. Ese número dice cuándo la ingeniería deja de ser el coste principal y si el servicio sale a cuenta.
Qué preguntar a un proveedor
Tres preguntas antes de firmar.
¿Quién va a trabajar con mi equipo, y durante cuánto tiempo?
¿Qué se construye solo para mí y qué se reutiliza?
¿Cuándo termina la construcción y empieza el mantenimiento?
Si la respuesta es «lo que haga falta», estás comprando horas, no resultados.
Para seguir leyendo
- Cómo trabajo
El proceso paso a paso, qué pagas y qué trabajo encaja.
- Copiloto o autopiloto: dónde está el dinero y dónde está el margen
Mi ensayo sobre la tesis de Sequoia y cómo elegir la primera tarea.
- a16z: The Palantirization of everything
El ensayo de Marc Andrusko, enero de 2026, en inglés.
- Palantir: Dev versus Delta
Cómo describe Palantir a sus forward deployed engineers, en inglés.
Ingeniería con fecha de fin
Escríbeme con una tarea que ya pagas a otros. Te digo si encaja y cuándo terminaría la construcción.
Cuéntame la tarea