El ingeniero de Anthropic imparte una clase introductoria a FDE
https://www.youtube.com/watch?v=KwhgfwOSToQ
Kevin Bai ahora está en el equipo de Applied AI de Anthropic. Antes fue miembro fundador del equipo de FDE en Rippling, y antes de eso trabajó durante varios años en Palantir. Recientemente hizo una presentación sobre FDE 101, explicando con claridad el rol del ingeniero de despliegue en primera línea, y vale la pena resumirla.
Primero, veamos un dato: en las empresas SaaS que cotizan en bolsa, ordenadas por el valor medio de los contratos, Palantir está en 4 millones de dólares; ServiceNow, en 1,2 millones; Workday, en 600.000; y las demás ninguna supera los 500.000. Palantir logra un ticket promedio que otros, con decenas de miles de personas, no consiguen, usando solo unos pocos miles. Eso se debe al modelo FDE.
Entonces, ¿qué problema resuelve FDE?
El producto de Palantir, Foundry, es una plataforma para construir aplicaciones, con un umbral técnico alto. Sin embargo, los compradores no son perfiles técnicos: son ejecutivos no técnicos de industrias como petróleo y bienes de consumo. Si le entregas una plataforma tecnológica compleja a alguien que no sabe programar y esperas que él mismo descubra cómo usarla, no es realista.
Por eso, el enfoque de Palantir es este: el cliente no compra un producto de software ni un servicio de consultoría, sino un “resultado”. Tú envías ingenieros para comprender en profundidad los escenarios de negocio del cliente y construirles lo que necesiten sobre la plataforma. A los clientes les importa cuánto aumentan los productos en los estantes, cuánto mejora la eficiencia de la línea de producción; no les importa cómo se organizan los datos, ni deberían preocuparse por ello.
¿En qué se diferencia FDE del desarrollo tercerizado?
Kevin enfatiza especialmente un punto: si tus ingenieros, cada vez, escriben código personalizado para el cliente desde cero, entonces lo que haces no es FDE; es desarrollo tercerizado. El modelo FDE solo tiene sentido si cuentas con una plataforma reutilizable. El ingeniero ensambla y personaliza sobre la base de capacidades ya existentes en la plataforma, en lugar de reinventar la rueda cada vez. Sin una plataforma, los costos de mantenimiento se comen todas las ganancias, y además los ingenieros terminarán huyendo al tener que mantener decenas de repositorios de código sin relación entre sí.
¿Conviene hacer FDE? Con dos preguntas basta.
Primera: ¿necesitas vender algo tecnológicamente complejo a compradores no técnicos? Si tus clientes ya son ingenieros, por ejemplo si vendes GitHub o Datadog, no necesitas FDE. Si tu producto, por naturaleza, es “listo para usar” —como Slack o Jira— tampoco lo necesitas. Solo cuando tu producto es muy complejo y el cliente no entiende la parte técnica, FDE tiene sentido.
Segunda: ¿tienes una plataforma reutilizable? ¿O estás dispuesto a invertir para construir una? Sin componentes base compartidos, FDE no es sostenible.
¿Cuál es el nuevo cambio en 2026?
La valoración de Kevin es interesante: la forma en que el sector del software hace negocios en sí ha cambiado. La IA hace que construir software sea extremadamente fácil, y casi todas las plataformas están avanzando hacia la “agencialización” (Agent-ification). Esto implica que casi todas las plataformas se vuelven altamente personalizables. Como consecuencia, cada vez más clientes no logran entender qué puede hacer realmente tu producto. Poner el éxito o fracaso de tu producto en manos del cliente para que lo descubra por su cuenta en la era de los agentes será cada vez más difícil de lograr.
Así, FDE deja de ser una estrategia minoritaria exclusiva de Palantir y pasa a ser algo que muchas empresas de software necesitan considerar seriamente.
Una última pregunta: ¿qué tipo de personas es adecuada para hacer FDE?
La respuesta de Kevin es muy directa: FDE es un tipo de ingeniería de software en la que tú confías lo suficiente en la persona como para que pueda enfrentarse directamente a los clientes. La capacidad técnica es la base, pero también tienes que estar tranquilo de que podrá representar a la empresa al relacionarse con los clientes.
https://www.youtube.com/watch?v=KwhgfwOSToQ
Kevin Bai ahora está en el equipo de Applied AI de Anthropic. Antes fue miembro fundador del equipo de FDE en Rippling, y antes de eso trabajó durante varios años en Palantir. Recientemente hizo una presentación sobre FDE 101, explicando con claridad el rol del ingeniero de despliegue en primera línea, y vale la pena resumirla.
Primero, veamos un dato: en las empresas SaaS que cotizan en bolsa, ordenadas por el valor medio de los contratos, Palantir está en 4 millones de dólares; ServiceNow, en 1,2 millones; Workday, en 600.000; y las demás ninguna supera los 500.000. Palantir logra un ticket promedio que otros, con decenas de miles de personas, no consiguen, usando solo unos pocos miles. Eso se debe al modelo FDE.
Entonces, ¿qué problema resuelve FDE?
El producto de Palantir, Foundry, es una plataforma para construir aplicaciones, con un umbral técnico alto. Sin embargo, los compradores no son perfiles técnicos: son ejecutivos no técnicos de industrias como petróleo y bienes de consumo. Si le entregas una plataforma tecnológica compleja a alguien que no sabe programar y esperas que él mismo descubra cómo usarla, no es realista.
Por eso, el enfoque de Palantir es este: el cliente no compra un producto de software ni un servicio de consultoría, sino un “resultado”. Tú envías ingenieros para comprender en profundidad los escenarios de negocio del cliente y construirles lo que necesiten sobre la plataforma. A los clientes les importa cuánto aumentan los productos en los estantes, cuánto mejora la eficiencia de la línea de producción; no les importa cómo se organizan los datos, ni deberían preocuparse por ello.
¿En qué se diferencia FDE del desarrollo tercerizado?
Kevin enfatiza especialmente un punto: si tus ingenieros, cada vez, escriben código personalizado para el cliente desde cero, entonces lo que haces no es FDE; es desarrollo tercerizado. El modelo FDE solo tiene sentido si cuentas con una plataforma reutilizable. El ingeniero ensambla y personaliza sobre la base de capacidades ya existentes en la plataforma, en lugar de reinventar la rueda cada vez. Sin una plataforma, los costos de mantenimiento se comen todas las ganancias, y además los ingenieros terminarán huyendo al tener que mantener decenas de repositorios de código sin relación entre sí.
¿Conviene hacer FDE? Con dos preguntas basta.
Primera: ¿necesitas vender algo tecnológicamente complejo a compradores no técnicos? Si tus clientes ya son ingenieros, por ejemplo si vendes GitHub o Datadog, no necesitas FDE. Si tu producto, por naturaleza, es “listo para usar” —como Slack o Jira— tampoco lo necesitas. Solo cuando tu producto es muy complejo y el cliente no entiende la parte técnica, FDE tiene sentido.
Segunda: ¿tienes una plataforma reutilizable? ¿O estás dispuesto a invertir para construir una? Sin componentes base compartidos, FDE no es sostenible.
¿Cuál es el nuevo cambio en 2026?
La valoración de Kevin es interesante: la forma en que el sector del software hace negocios en sí ha cambiado. La IA hace que construir software sea extremadamente fácil, y casi todas las plataformas están avanzando hacia la “agencialización” (Agent-ification). Esto implica que casi todas las plataformas se vuelven altamente personalizables. Como consecuencia, cada vez más clientes no logran entender qué puede hacer realmente tu producto. Poner el éxito o fracaso de tu producto en manos del cliente para que lo descubra por su cuenta en la era de los agentes será cada vez más difícil de lograr.
Así, FDE deja de ser una estrategia minoritaria exclusiva de Palantir y pasa a ser algo que muchas empresas de software necesitan considerar seriamente.
Una última pregunta: ¿qué tipo de personas es adecuada para hacer FDE?
La respuesta de Kevin es muy directa: FDE es un tipo de ingeniería de software en la que tú confías lo suficiente en la persona como para que pueda enfrentarse directamente a los clientes. La capacidad técnica es la base, pero también tienes que estar tranquilo de que podrá representar a la empresa al relacionarse con los clientes.