Quando um Dev Sênior Não É o Suficiente

Quando um dev sênior não é suficiente para um projeto de IA: as decisões que apenas um fractional CTO pode tomar, o que o papel realmente faz, e quando pular a contratação inteiramente.

20 de junho de 2026
9 min de leitura
Tags
fractional-cto-aifractional-ctoai-consultingengineering-leadershipstartup

Umas semanas atrás, um founder me procurou: time pequeno, seis engenheiros, feature de IA em produção, crescendo rápido. Coisa que a gente vê muito hoje em dia. Eles tinham um dev sênior ótimo. Ótimo mesmo. Daqueles que respondem pergunta difícil e não fogem de problema.

O problema é que não havia problema de código pra ele resolver. As decisões que estavam se acumulando eram de outro tipo.

Migrar de um provedor de modelo pra outro? Construir a própria camada de busca ou usar uma gerenciada? Hospedar o banco vetorial ou deixar num SaaS? Como tratar a residência de dados dos clientes europeus? Qual abordagem de avaliação usar? Quando "bom o bastante" queria dizer publicar, e quando queria dizer continuar iterando? O dev sênior tinha opinião sobre tudo isso, mas eram opiniões de engenharia. Ele sabia te dizer três jeitos diferentes de fazer cada coisa. O que ele não sabia dizer era qual escolha fazia sentido pro negócio, porque esse não era o trabalho dele, e não era justo pedir que fosse.

Várias vezes na minha carreira, eu fui esse dev. Quando você não sabe pra onde quer ir, qualquer caminho serve.

É nessa hora que um fractional CTO entra num projeto de IA: quando alguém precisa tomar decisões guiadas pelo negócio.

O que um fractional CTO faz

O título soa como uma versão diluída de um CTO em tempo integral. Na prática é outro papel, com outro formato.

O CTO em tempo integral é dono da tecnologia. Contrata, demite, define o roadmap, senta nas reuniões da diretoria e responde pelos resultados ao longo da vida da empresa. O fractional CTO não faz nada disso, e nem deveria. O papel está mais perto de um consultor sênior com autoridade pra executar decisões específicas.

Num projeto de IA, o trabalho se divide em cinco frentes.

Decisões que pedem profundidade técnica e contexto de negócio ao mesmo tempo. Construir ou comprar? Otimizar pra velocidade ou pra precisão neste caso? Quanto gastar em infraestrutura agora e quanto dá pra adiar? Não é decisão do dev sênior, e também não é do founder, que não tem o contexto técnico pra pesar os prós e contras.

Decisões de arquitetura com consequência de longo prazo. O que você decide hoje sobre banco vetorial, gestão de prompts, avaliação e observabilidade define o que vai ser possível (e o que vai ser caro) daqui a dezoito meses. Time pequeno costuma tomar essas decisões numa reunião de planejamento de sprint e pagar por elas durante anos. O fractional CTO é quem olha pra arquitetura proposta e faz as perguntas que ninguém no time tem senioridade pra fazer.

Tradução entre o time e o resto da empresa. O founder pergunta "dá pra adicionar essa feature?". O dev sênior responde "dá, mas leva três semanas". O fractional CTO é quem diz "dá, são três semanas de desenvolvimento, mas isso obriga a mexer na camada de busca, o que afeta todas as outras features, e a ordem certa é fazer essas duas outras coisas antes". A maioria dos times não tem quem faça essa tradução, e a maioria dos projetos travados precisa exatamente disso.

Contratação pra papéis específicos de IA. Como é um bom engenheiro de ML, comparado com um bom engenheiro de infraestrutura que por acaso conhece as APIs de LLM? Quando você precisa de alguém dedicado só a avaliação? Quando o time atual dá conta e só precisa de apoio? Time pequeno erra muito aqui, porque contrata o que acha que precisa a partir das descrições de vaga que viu por aí.

Uma segunda opinião que não está na folha de pagamento. O dev sênior do time tem incentivos de carreira. Dizer "não sei fazer isso" ou "acho que erramos seis meses atrás" é mais difícil quando você quer manter o emprego. O fractional CTO não tem esse incentivo. Questionar o time e a gestão faz parte do trabalho.

O que um fractional CTO não é

Programador. Se o contrato vira entregar feature, o fractional CTO está sendo mal usado, e a empresa está pagando preço de consultoria sênior por um trabalho que um engenheiro pleno deveria fazer.

Gerente de projeto. Quando o fractional CTO vira gerente de projeto, é sinal de que o time tem um buraco enorme de liderança que precisa ser resolvido. Se o time precisa de um PM, contrate um PM. Custa menos e faz isso melhor.

Vendedor. Tem fractional CTO que é basicamente a cara técnica de uma consultoria, posto ali pra vender mais serviço. Se o seu vive recomendando fornecedores de fora, principalmente os que têm relação com ele, tem um conflito de interesse aí que merece atenção.

Solução permanente. Os bons trabalham pra sair do papel em doze a dezoito meses, seja ajudando você a contratar um CTO em tempo integral, seja deixando o time num ponto em que ainda não precisa de um. Quem é fractional CTO da mesma empresa pequena há três anos já deixou de ser fractional.

Quando você precisa de um fractional CTO

A maioria das empresas em estágio inicial não precisa. Elas precisam de engenheiros seniores e de um founder que consiga decidir. Colocar um fractional CTO em cima disso é custo que não se paga.

Você começa a precisar quando estas coisas passam a ser verdade ao mesmo tempo:

  • A parte de IA do produto é crítica a ponto de um erro custar clientes, dinheiro, ou os dois.
  • Seus engenheiros seniores são excelentes, mas não são as pessoas certas pra tomar decisões estratégicas de tecnologia, seja por falta de experiência nisso, seja porque você não os contratou pra isso.
  • Você ainda não está pronto pra um CTO em tempo integral, porque não cabe no caixa, porque a empresa não está nesse estágio ou porque ainda não achou a pessoa certa.
  • Tem decisão travando o time agora, e o custo de errar é maior que o custo de buscar ajuda de fora.

Se duas dessas quatro são verdade, você provavelmente se vira com algumas conversas de consultoria de vez em quando. Se três ou quatro são, um fractional CTO é quase obrigatório.

Se nenhuma é verdade, você não precisa de um. Gaste esse dinheiro com coisas que deixem os seus devs mais felizes.

Como fica o trabalho na prática

A maioria dos meus contratos de fractional CTO roda dois dias por semana, às vezes três nos períodos mais pesados. O trabalho se divide mais ou menos em três partes.

Estratégia. Revisão de arquitetura, decisões de construir ou comprar, avaliação de opções e recomendações por escrito que o time pode consultar depois. É a parte mais visível e a que os founders costumam esperar.

Time. Conversas individuais com os engenheiros seniores. Revisão de pull requests nas partes estrategicamente importantes do sistema. Programar em par nos problemas difíceis quando isso ensina algo ao time. Frear o instinto do time de complicar demais, ou de simplificar demais, coisas específicas. Um time que passa seis meses recebendo questionamento semanal de alguém de fora, atento, termina esses seis meses bem melhor, independente do que foi entregue.

Liderança. Sentar em reunião de conselho quando o assunto é IA. Escrever a parte técnica das atualizações pros investidores, pro founder não precisar. Ajudar a montar descrição de vaga, roteiro de entrevista e faixa salarial pras contratações técnicas. Ser quem o founder chama quando chega uma proposta de integração com um fornecedor e alguém precisa ler o contrato com olho de engenharia. Essa parte aparece menos, mas muitas vezes é onde está o maior valor.

A divisão varia. Tem contrato que é 80% estratégia e 20% time. Tem o contrário. O formato tem que seguir o que a empresa precisa, e não um modelo fixo.

Quanto custa um fractional CTO?

Vou dizer uma coisa que a maioria dos consultores não diz: a hora de fractional CTO é mais cara que a hora de desenvolvimento, e o valor nem sempre aparece no primeiro mês. Você está pagando por critério, pelos erros que deixou de cometer e por ter alguém pra chamar quando precisa. Nada disso aparece com clareza numa lista de entregas.

Isso quer dizer que o contrato só funciona quando a empresa está num estágio em que decisão ruim sai cara o bastante pra justificar o custo de acertar. Antes de encontrar o product-market fit, é melhor usar esse dinheiro pra contratar mais um engenheiro. Depois da tração, quando uma decisão de arquitetura errada pode custar seis meses de refatoração, a conta muda.

Um teste útil: se o seu engenheiro sênior tomasse amanhã uma decisão que se mostrasse errada, o erro custaria mais ou menos que três meses de fractional CTO? Se custar menos, você ainda não precisa disso.

Onde isso entra no resto do seu investimento em IA

Um fractional CTO não substitui o que eu cobri no post sobre como contratar um consultor de IA pra um projeto específico, nem no post sobre por que o problema não está nos seus prompts. Esses são contratos com escopo e entregas.

As empresas que eu vi fazendo isso bem usam os três em momentos diferentes. Trazem um consultor pra construir a primeira versão. Trazem um arquiteto quando a primeira versão para de funcionar. Trazem um fractional CTO quando o time já é grande o bastante pra precisar de liderança e ainda pequeno demais pra uma contratação em tempo integral. Três necessidades diferentes, três contratos diferentes.

Se as decisões estratégicas estão se acumulando mais rápido do que o seu time consegue tomá-las direito, e um CTO em tempo integral ainda não se justifica, isso é um arranjo de fractional CTO. Dois dias por semana, escopo por escrito, saída combinada. O objetivo é deixar você num ponto em que não precise mais de mim. Comece por aqui.

Leia Mais Artigos

Mais artigos pra ler

Voltar para o Blog