# Forward Deployed Engineering: qué es y cómo trabaja un FDE

> Qué es Forward Deployed Engineering, qué hace un FDE, qué habilidades pide y en qué se diferencia de una consultora o una fábrica de software. Con un caso real.

Crónica N.º 03 · Criterio · 7 de octubre de 2026 · Actualizada 21 de octubre de 2026 · 11 min de lectura
Firma: Alfonso Ponzellini, cofundador y director de Mithandir · https://mithandir.com/blog/forward-deployed-engineering

Forward Deployed Engineering (FDE) es un modelo de trabajo en el que ingenieros de software se meten en la operación del cliente para entender un problema concreto, construir la solución conectada a sus sistemas y quedarse hasta que funciona en producción y se puede medir. El forward deployed engineer no espera un pliego de requisitos: lo arma él, con quienes hacen el trabajo todos los días.

Esta guía explica qué es, qué hace un FDE, qué habilidades pide, en qué se diferencia de una consultora y de una fábrica de software, y cuándo conviene. La escribimos desde adentro: en Mithandir trabajamos así, y al final mostramos un caso con sus números. Si buscás el servicio, está en [Forward Deployed Engineering](/servicios/forward-deployed-engineering).

## Qué es Forward Deployed Engineering, en una frase y en detalle

En una frase: **acercar la ingeniería al negocio hasta que el problema operativo queda resuelto, no hasta que se entrega el software.**

En detalle, el modelo junta tres cosas que normalmente están separadas:

1. **Entender la operación.** Quién recibe el pedido, quién lo carga, qué sistema lo registra, dónde se traba y por qué.
2. **Construir.** Software, integraciones, automatizaciones e inteligencia artificial, conectados a lo que la empresa ya usa: su sistema de gestión, WhatsApp, planillas, el CRM, la facturación electrónica.
3. **Hacerse cargo del resultado.** Poner el sistema en producción, ver cómo lo usa la gente, corregirlo y medir si cambió algo.

Tener contacto con el cliente o programar a medida, por separado, no alcanza para hablar de FDE. Lo que define al modelo es que las tres cosas las hace el mismo equipo, sin pasarse la pelota.

## De dónde viene el término

El término se hizo conocido con Palantir, que llama Forward Deployed Software Engineer a los ingenieros que trabajan con cada cliente. Su descripción oficial del puesto abarca desde la primera conversación con el cliente hasta decisiones de arquitectura, manejo de datos, construcción de aplicaciones y la relación con usuarios y ejecutivos.

Con la llegada de los modelos de lenguaje, empresas de IA adoptaron el mismo nombre. Anthropic describe a su Forward Deployed Engineer como quien lleva aplicaciones de IA a los sistemas del cliente, construye piezas como servidores MCP, acompaña el despliegue y convierte lo que aprende en patrones reutilizables. Comparamos los dos enfoques en [Palantir y Mithandir](/blog/palantir-y-mithandir).

El motivo del auge es simple: un modelo de IA no rinde nada mientras no esté conectado a los datos y a las reglas de una empresa en particular. Esa conexión no la hace el modelo; la hace alguien que entiende la operación.

## Qué hace un forward deployed engineer en el día a día

Una semana típica de un FDE tiene poco de escribir código en silencio y mucho de ir y volver entre la operación y el sistema:

- **Mirar el trabajo como es, no como está documentado.** En una distribuidora, eso significa leer los mensajes reales de los vendedores: listas pegadas, audios, fotos de una planilla escrita a mano.
- **Convertir lo ambiguo en decisiones.** «El cliente pide fernet» es un problema técnico: hay dos presentaciones y cada cliente lo llama distinto.
- **Construir dentro del entorno del cliente.** Conectar con su sistema de gestión, con permisos de sólo lectura cuando es productivo, y escribir recién cuando una persona confirma.
- **Probar con quienes lo van a usar.** No con un usuario de prueba: con la persona de administración que hasta ayer tipeaba los pedidos.
- **Medir y corregir.** Cuántas veces el sistema propuso bien, cuántas lo corrigió una persona, qué falló y cuándo se supo.
- **Dejar todo por escrito.** Las decisiones, los cambios y por qué se hicieron, para que el sistema no dependa de una sola persona.

## Habilidades de un forward deployed engineer

Las habilidades de un FDE son más anchas que las de un desarrollador y más profundas que las de un consultor. Las agrupamos en cinco:

| Habilidad | Qué significa en la práctica |
| --- | --- |
| Ingeniería de software completa | Construir de punta a punta: base de datos, servidor, interfaz y despliegue, sin depender de otro equipo para cada capa |
| Integración de sistemas | Conectarse a un ERP, una API, WhatsApp o una planilla que nadie documentó, y que el dato entre una sola vez |
| Lectura de la operación | Entender procesos, roles y restricciones del negocio, y hablar con quien opera tanto como con quien firma |
| IA aplicada con criterio | Saber cuándo usar un modelo y cuándo alcanza con reglas; medir acierto y correcciones; diseñar qué pasa cuando el modelo duda |
| Responsabilidad por producción | Monitoreo, avisos, corrección de errores y seguimiento del uso después de la entrega |

En proyectos con IA la cuarta fila es la que más separa a un FDE de un desarrollador. La pregunta no es «¿qué modelo uso?», sino «¿qué hace el sistema cuando no está seguro?». En nuestro caso de distribuidoras, la respuesta fue que no elige: pregunta. Si «fernet» puede ser el de 750 ml o el de un litro, le ofrece las dos opciones al vendedor, y la respuesta queda guardada para ese cliente.

## FDE, consultora y fábrica de software: en qué se diferencian

Las tres pueden terminar en un sistema funcionando. La diferencia está en quién define el problema, cuándo termina el trabajo y por qué responde cada una.

| | Equipo de Forward Deployed Engineering | Consultora tradicional | Fábrica de software |
| --- | --- | --- | --- |
| Qué entrega | Un proceso que funciona en producción, medido | Un diagnóstico y una recomendación | El software que se especificó |
| Quién define el alcance | El equipo, con quienes operan el proceso | La consultora, con la dirección | El cliente, en un pliego |
| Dónde trabaja | Adentro de la operación y de los sistemas del cliente | En reuniones y entrevistas | En su propio entorno |
| Cuándo termina | Cuando el sistema se usa y se puede medir | Cuando se presenta el informe | Cuando se entrega lo pedido |
| Cómo se mide | Por el cambio en la operación | Por la calidad del diagnóstico | Por cumplir la especificación |
| Riesgo típico | Depender del acceso a usuarios y datos | Que el informe no se implemente | Construir bien lo que no hacía falta |

Ninguna es mejor en abstracto. Si el problema está claro y la especificación es buena, una fábrica de software es eficiente. Si lo que falta es decidir qué hacer, una consultora puede alcanzar. Forward Deployed Engineering conviene cuando el problema está en el medio: nadie sabe bien qué construir hasta mirar el trabajo de cerca, y lo que se construya tiene que convivir con sistemas que ya existen.

## Lo que FDE no es

Hay dos lecturas del término que conviene descartar, porque son las que más se venden y las que menos rinden.

**No es poner un programador en la oficina del cliente.** La presencia física no define nada. Lo que define es el acceso a usuarios, datos y decisiones. Trabajamos de forma remota con clientes de otras ciudades y países, y el modelo funciona igual, siempre que esas tres puertas estén abiertas.

**No es «ponerle IA» a todo.** La mitad del trabajo de un FDE en proyectos de IA es decir que no. Si lo que entra al proceso ya viene ordenado, como un extracto bancario o una orden de trabajo, alcanza con reglas, que son más baratas y más previsibles. La IA se justifica cuando el dato lo escribe una persona: un audio, una lista pegada, una frase.

Y una tercera, menos obvia: **el trabajo no termina con la entrega.** Termina cuando el sistema sigue funcionando sin nosotros mirándolo todo el día.

## Un caso medido: los pedidos de WhatsApp de dos distribuidoras

Vinesco distribuye bebidas y la otra, alimentos congelados, las dos en Rosario. Sus vendedores mandan los pedidos por WhatsApp, y alguien de administración los volvía a tipear, uno por uno, en el sistema de gestión. El caso completo está en [Los pedidos de WhatsApp se cargan solos](/projects/distribuidoras-core); acá contamos lo que tiene de Forward Deployed Engineering.

**No cambiamos el canal.** La primera idea que aparece siempre es pedirle a los vendedores que usen un formulario o una app. Casi nunca funciona: el vendedor va a seguir mandando el mensaje, porque es lo que le sirve. Así que el sistema se puso atrás de WhatsApp: lee el mensaje, arma el pedido contra el catálogo y una persona lo confirma en un panel antes de registrarlo.

**Los números, medidos en los registros de los paneles:**

- En Vinesco, del mensaje al pedido emitido pasan **7,5 minutos de mediana** (del 7 al 26 de agosto de 2026).
- El **100 %** de lo confirmado en el panel de Vinesco quedó registrado en su sistema de gestión: **908 de 908** documentos entre el 7 de agosto y el 1 de septiembre, cada uno confirmado por una persona.
- A mediados de septiembre, el panel ya emitía **1.216 documentos en 30 días**.
- En la distribuidora de alimentos congelados, del 1 al 9 de septiembre, el **59 %** de los renglones de pedido salió sin que nadie los tocara.
- Pedidos, pagos, traspasos entre depósitos y presupuestos pasaron de **4 lugares a una sola bandeja**.

**Lo que el uso nos hizo cambiar.** Una mañana hubo un error de registro que se supo recién al mediodía. Desde ese día, cada 15 minutos el sistema revisa que todo lo confirmado haya quedado registrado y, si algo falló, le manda a administración un solo mensaje con todo junto. Ese tipo de decisión no sale de un pliego: sale de estar cerca cuando algo se rompe.

**Lo que aprendimos de la primera a la segunda.** Con Vinesco empezamos en noviembre de 2025 y el panel pasó a producción en agosto de 2026. La distribuidora de alimentos congelados arrancó en marzo de 2026 viendo cómo funcionaba en Vinesco y en julio ya operaba en su propio panel. Lo que se repitió en las dos hoy es un producto, Mithandir Core. Esa es la última parte del modelo: convertir lo aprendido en piezas que la siguiente instalación no tiene que volver a inventar.

Si tenés una distribuidora y querés ver si te pasa lo mismo, armamos una página para el rubro: [pedidos de WhatsApp para distribuidoras](/rubros/distribuidoras), y una [calculadora de las horas que se van en cargar pedidos](/herramientas/calculadora-pedidos).

## Cómo trabaja un equipo FDE, paso a paso

Así lo hacemos nosotros. No es la única forma, pero es la que nos funcionó en producción.

1. **Relevamiento en la operación.** Mirar el trabajo real antes de proponer nada: mensajes, planillas, pantallas, quién hace qué. Sale una lista corta de problemas, ordenada por lo que cuestan.
2. **Un proceso acotado primero.** Elegimos uno que se pueda medir pronto. En las distribuidoras fue la carga de pedidos, no «la administración entera».
3. **Lectura antes que escritura.** Nos conectamos a los sistemas del cliente en modo de sólo lectura. Escribimos recién cuando una persona confirma.
4. **Prueba con los usuarios reales.** El panel se prueba con quien va a usarlo, con datos reales, antes de encenderlo.
5. **Producción con red.** Avisos cuando algo falla, un registro de cada cambio y una persona que puede frenar el sistema.
6. **Medición antes y después.** Tiempo por documento, correcciones, pendientes y uso. Si el número no se mueve, se revisa la solución.
7. **Lo que se repite, se vuelve producto.** Y la siguiente empresa arranca más cerca del final.

En una cadena de peluquerías con locales en tres países, ese paso a paso llevó a un traspaso completo de 67 días desde el primer local, sin cerrar ninguno. Está contado en el [caso Pelokitos](/projects/pelokitos).

## Cuándo conviene y cuándo no

**Conviene si:**

- El problema está en la operación y nadie sabe bien qué construir hasta mirarla de cerca.
- La empresa ya tiene sistemas que no quiere tirar, y lo nuevo tiene que convivir con ellos.
- No hay un área de sistemas que traduzca el negocio a requisitos.
- Lo que entra al proceso lo escribe una persona, distinto cada vez, y ahí la IA puede ayudar.

**No conviene si:**

- El problema ya está especificado y sólo falta construirlo: una fábrica de software va a ser más barata.
- No hay acceso a usuarios ni a datos. Sin eso, el modelo no funciona, por más buena que sea la ingeniería.
- Lo que se busca es un informe para decidir más adelante.

## Qué tiene que poner el cliente

Forward Deployed Engineering no es un servicio que se compra y se recibe. Para que funcione, el cliente tiene que poner:

- **Un referente** que conozca el proceso y tenga tiempo para responder.
- **Acceso a las personas que operan**, no sólo a quien decide.
- **Acceso a los datos y a los sistemas**, con los permisos que correspondan.
- **Un criterio de éxito acordado** antes de empezar: qué número tiene que cambiar.

Del lado del equipo FDE va un referente técnico que entienda el negocio, un backlog ordenado por impacto, criterios claros para pasar a producción y un seguimiento con alcance definido. Entregar tareas y cerrar tickets demuestra capacidad de desarrollo; sostener el modelo FDE pide además responder por el problema operativo.

## Qué es Mithandir y qué no

Mithandir es una consultora de Rosario que trabaja con el enfoque de Forward Deployed Engineering: un equipo de ingeniería integrado a la operación de cada cliente, que construye software, automatizaciones e inteligencia artificial conectados con sus sistemas reales. No somos una agencia ni una fábrica de horas.

Conviene ser precisos con la comparación. Un FDE de Palantir o de Anthropic despliega y extiende la tecnología de su empleador; nosotros combinamos herramientas de distintos proveedores con desarrollos propios, para empresas de otro tamaño. La equivalencia es de enfoque y de responsabilidades, no de escala. Y repartimos el trabajo entre perfiles de negocio, gestión y desarrollo, en lugar de concentrarlo en una sola persona: por eso hablamos de un equipo de Forward Deployed Engineering y no de que cada integrante sea un FDE.

Si querés ver si tu operación se presta para este modelo, [contanos cómo trabaja tu empresa hoy](/contacto).

## Fuentes primarias

- [Palantir, descripción oficial del puesto Forward Deployed Software Engineer](https://jobs.lever.co/palantir/5168e8fd-fec1-4fea-b7a1-81bdaea65850)
- [Anthropic, descripción oficial del puesto Forward Deployed Engineer](https://job-boards.greenhouse.io/anthropic/jobs/5423029008)

Las descripciones de puestos fueron consultadas el 7 de octubre de 2026 y pueden cambiar. Las cifras del caso salen de los registros de los paneles de Vinesco (agosto de 2026) y de la distribuidora de alimentos congelados (primeras semanas de septiembre de 2026), publicadas en el caso de estudio. La comparación con Palantir y Anthropic es un análisis propio.

## Preguntas frecuentes

### ¿Qué significa «forward deployed»?

Que el ingeniero está desplegado del lado del cliente, cerca de la operación, y no en la oficina del proveedor esperando un pliego. Es una expresión que viene del vocabulario militar: la unidad que trabaja en el frente, donde pasan las cosas.

### ¿Un FDE es un programador que trabaja en la oficina del cliente?

No necesariamente. Lo que lo define es el acceso: a las personas que operan el proceso, a los datos reales y a quien decide las prioridades. Se puede trabajar de forma remota y ser FDE, y se puede estar todos los días en la oficina y no serlo, si lo único que se hace es resolver tickets.

### ¿Qué habilidades necesita un forward deployed engineer en proyectos con IA?

Las de un buen ingeniero de software, más tres que en IA pesan el doble: saber cuándo un problema no necesita IA, poder medir cuántas veces el modelo acierta y cuántas lo corrige una persona, y diseñar el circuito para que, cuando el modelo duda, pregunte en lugar de elegir.

### ¿Forward Deployed Engineering es lo mismo que staff augmentation?

No. En staff augmentation se alquilan horas de una persona que sigue las órdenes del cliente. Un equipo FDE responde por un resultado operativo: propone qué construir, lo construye, lo pone en producción y mide si cambió algo. Si el sistema no se usa, el trabajo no está terminado.

### ¿Una pyme puede trabajar con un equipo de Forward Deployed Engineering?

Sí, y es donde más rinde, porque una pyme no suele tener un área de sistemas que traduzca el negocio a requisitos. Las distribuidoras de nuestro caso tienen administraciones chicas: el equipo FDE hace esa traducción y la sostiene mientras el sistema se usa.

### ¿Cuánto tarda en verse un resultado?

Una primera versión para probar puede estar en semanas; que funcione en producción lleva más. En la primera distribuidora pasaron nueve meses entre el comienzo y el panel en producción; en la segunda, que partió de lo aprendido, cuatro.

---

Más crónicas: https://mithandir.com/blog · Hablar con el equipo: https://mithandir.com/contacto