O engenheiro da Anthropic dá uma aula introdutória sobre FDE
https://www.youtube.com/watch?v=KwhgfwOSToQ
Kevin Bai agora está no time de Applied AI da Anthropic. Antes, foi um dos membros fundadores do time de FDE da Rippling; ainda antes, trabalhou por vários anos na Palantir. Recentemente, ele fez uma apresentação de “FDE 101”, explicando de forma bem clara o papel do engenheiro de implantação na linha de frente — vale a pena resumir.
Primeiro, um dado: em empresas SaaS listadas, classificando por valor médio do contrato, a Palantir tem US$ 4 milhões, a ServiceNow US$ 1,2 milhão, a Workday US$ 0,6 milhão; o restante nenhuma chega a passar de US$ 0,5 milhão. A Palantir conseguiu, com apenas alguns milhares de pessoas, atingir um ticket médio que outras fariam com dezenas de milhares. O segredo está no modelo FDE.
Então, afinal, o que o FDE resolve?
O produto da Palantir, Foundry, é uma plataforma de construção de aplicações com alto nível de exigência técnica, mas os compradores são executivos não técnicos — como de petróleo e bens de consumo. Você entregar uma plataforma tecnológica complexa para alguém que não sabe programar e esperar que essa pessoa descubra sozinha como usá-la não é realista.
Por isso, a abordagem da Palantir é esta: o cliente compra algo que não é um produto de software nem um serviço de consultoria, e sim um “resultado”. Você envia engenheiros para lá, entende profundamente os cenários de negócio do cliente e constrói as coisas na plataforma. O que o cliente se importa é quantas mercadorias a mais entram nas prateleiras, em quanto a eficiência das linhas de produção melhora; eles não se importam com como os dados são organizados — e nem precisam se importar.
Qual é a diferença entre FDE e desenvolvimento terceirizado?
Kevin enfatiza especialmente um ponto: se seus engenheiros, toda vez, começam do zero e escrevem código personalizado para o cliente, então o que você está fazendo não é FDE, é desenvolvimento terceirizado. O modelo FDE só se sustenta se você tiver uma plataforma reutilizável. Os engenheiros montam e customizam com base nas capacidades já existentes da plataforma, e não ficam reinventando a roda toda vez. Sem uma plataforma, os custos de manutenção vão consumir todo o lucro, e os engenheiros também vão acabar saindo, porque precisariam manter dezenas de repositórios de código sem relação entre si.
Vale a pena fazer FDE? Dois problemas já respondem.
Primeiro: você precisa vender algo tecnologicamente complexo para um comprador não técnico? Se seus clientes são, por natureza, engenheiros — por exemplo, quando você vende GitHub ou Datadog — então não precisa de FDE. Se seu produto já é pronto para uso, como Slack ou Jira, também não precisa. Só quando seu produto é muito complexo e o cliente não entende de tecnologia é que o FDE faz sentido.
Segundo: você tem uma plataforma reutilizável? Ou você está disposto a investir para construí-la? Sem componentes básicos compartilháveis, o FDE não é sustentável.
Quais são as mudanças novas em 2026?
A avaliação do Kevin é interessante: o jeito de fazer negócio na indústria de software mudou. Com a IA, construir software fica extremamente fácil, e quase todas as plataformas estão indo na direção de uma abordagem baseada em agentes (Agent). Isso significa que quase todas as plataformas vão se tornar altamente customizáveis. A consequência é que cada vez mais clientes não conseguem entender exatamente o que o seu produto consegue fazer. Entregar o sucesso ou fracasso do seu produto para o cliente descobrir por conta própria, na era dos agentes, fica cada vez mais difícil.
Isso transforma o FDE, antes um modelo exclusivo e nichado da Palantir, em algo que mais empresas de software precisam considerar seriamente.
Por fim: que tipo de pessoa é adequada para fazer FDE?
A resposta do Kevin é bem direta: FDE é um engenheiro de software em quem você confia a ponto de deixá-lo lidar diretamente com o cliente. Capacidade técnica é a base, mas você também precisa ter segurança para permitir que ele represente a empresa na interação com o cliente.
https://www.youtube.com/watch?v=KwhgfwOSToQ
Kevin Bai agora está no time de Applied AI da Anthropic. Antes, foi um dos membros fundadores do time de FDE da Rippling; ainda antes, trabalhou por vários anos na Palantir. Recentemente, ele fez uma apresentação de “FDE 101”, explicando de forma bem clara o papel do engenheiro de implantação na linha de frente — vale a pena resumir.
Primeiro, um dado: em empresas SaaS listadas, classificando por valor médio do contrato, a Palantir tem US$ 4 milhões, a ServiceNow US$ 1,2 milhão, a Workday US$ 0,6 milhão; o restante nenhuma chega a passar de US$ 0,5 milhão. A Palantir conseguiu, com apenas alguns milhares de pessoas, atingir um ticket médio que outras fariam com dezenas de milhares. O segredo está no modelo FDE.
Então, afinal, o que o FDE resolve?
O produto da Palantir, Foundry, é uma plataforma de construção de aplicações com alto nível de exigência técnica, mas os compradores são executivos não técnicos — como de petróleo e bens de consumo. Você entregar uma plataforma tecnológica complexa para alguém que não sabe programar e esperar que essa pessoa descubra sozinha como usá-la não é realista.
Por isso, a abordagem da Palantir é esta: o cliente compra algo que não é um produto de software nem um serviço de consultoria, e sim um “resultado”. Você envia engenheiros para lá, entende profundamente os cenários de negócio do cliente e constrói as coisas na plataforma. O que o cliente se importa é quantas mercadorias a mais entram nas prateleiras, em quanto a eficiência das linhas de produção melhora; eles não se importam com como os dados são organizados — e nem precisam se importar.
Qual é a diferença entre FDE e desenvolvimento terceirizado?
Kevin enfatiza especialmente um ponto: se seus engenheiros, toda vez, começam do zero e escrevem código personalizado para o cliente, então o que você está fazendo não é FDE, é desenvolvimento terceirizado. O modelo FDE só se sustenta se você tiver uma plataforma reutilizável. Os engenheiros montam e customizam com base nas capacidades já existentes da plataforma, e não ficam reinventando a roda toda vez. Sem uma plataforma, os custos de manutenção vão consumir todo o lucro, e os engenheiros também vão acabar saindo, porque precisariam manter dezenas de repositórios de código sem relação entre si.
Vale a pena fazer FDE? Dois problemas já respondem.
Primeiro: você precisa vender algo tecnologicamente complexo para um comprador não técnico? Se seus clientes são, por natureza, engenheiros — por exemplo, quando você vende GitHub ou Datadog — então não precisa de FDE. Se seu produto já é pronto para uso, como Slack ou Jira, também não precisa. Só quando seu produto é muito complexo e o cliente não entende de tecnologia é que o FDE faz sentido.
Segundo: você tem uma plataforma reutilizável? Ou você está disposto a investir para construí-la? Sem componentes básicos compartilháveis, o FDE não é sustentável.
Quais são as mudanças novas em 2026?
A avaliação do Kevin é interessante: o jeito de fazer negócio na indústria de software mudou. Com a IA, construir software fica extremamente fácil, e quase todas as plataformas estão indo na direção de uma abordagem baseada em agentes (Agent). Isso significa que quase todas as plataformas vão se tornar altamente customizáveis. A consequência é que cada vez mais clientes não conseguem entender exatamente o que o seu produto consegue fazer. Entregar o sucesso ou fracasso do seu produto para o cliente descobrir por conta própria, na era dos agentes, fica cada vez mais difícil.
Isso transforma o FDE, antes um modelo exclusivo e nichado da Palantir, em algo que mais empresas de software precisam considerar seriamente.
Por fim: que tipo de pessoa é adequada para fazer FDE?
A resposta do Kevin é bem direta: FDE é um engenheiro de software em quem você confia a ponto de deixá-lo lidar diretamente com o cliente. Capacidade técnica é a base, mas você também precisa ter segurança para permitir que ele represente a empresa na interação com o cliente.