Toda empresa virou software house?
Construir o diferencial é uma coisa. Sustentá-lo é outra.
Toda empresa virou software house?
Construir o diferencial é uma coisa. Sustentá-lo é outra.
O software é seu. O problema também.
Por esses dias, li um texto de um grande amigo e fiquei pensando nele por um bom tempo.
O Victor Couto escreveu:
“Compre o que te iguala. Construa o diferencial.”
Em resumo, ele fala sobre a decisão entre comprar um software de prateleira e construir um sistema próprio.
Achei o texto tão cirúrgico que chamei o Victor para continuar o debate.
Depois de trabalhar alguns anos em software houses, vi muitas empresas errarem dos dois lados.
Algumas compram tantos sistemas que a operação vira um quebra-cabeça de planilhas e integrações manuais.
Outras decidem construir tudo dentro de casa e descobrem, tarde demais, que contratar alguns desenvolvedores não transforma ninguém em uma empresa de tecnologia.
Quero fazer uma dobra a mais na reflexão do Victor.
E, para isso, preciso contar a história do Adriano.
Antes de continuar: Adriano é um personagem fictício. Eu o inventei enquanto dirigia e pensava nesta newsletter.
Ele não existe.
Os problemas dele, sim.
A empresa do Adriano
Adriano é um empresário muito foda.
Ele assumiu a empresa da família, encarou a responsabilidade e começou a organizar a casa. Quem trabalha lá comenta o quanto a empresa mudou depois que ele assumiu.
Adriano é formado em Administração, tem pós-graduação em Finanças e conhece profundamente o negócio. É um cara safo, inquieto e visionário.
Conforme a empresa cresceu, ele contratou softwares para diferentes áreas.
Hoje são 12 sistemas.
O problema é que quase nenhum conversa direito com os outros.
Sempre que precisa tomar uma decisão financeira importante, Adriano cruza dados do ERP com uma plataforma de BPO. Exporta uma informação, ajusta outra e confere os resultados manualmente.
Esse processo consome quase seis horas da semana dele.
Adriano já testou 16 ferramentas diferentes. Sempre encontrou o mesmo problema: alguma parte importante da operação não era atendida.
Então começou a sonhar com um sistema específico para a empresa.
Um software construído ao redor da forma como ela realmente funciona.
Adriano percebeu que as ferramentas de inteligência artificial evoluíram muito.
Claude Code e Codex já conseguem escrever boa parte de uma aplicação. Então ele decidiu desenvolver o próprio sistema.
Como escrevi na última newsletter, todo mundo virou dev:
O projeto começou a todo vapor.
Claude Code e Codex moendo.
Telas bonitas. Navegação limpa. Dashboard organizado.
O sistema parecia perfeito.
Até o momento em que outras pessoas começaram a usá-lo.
O primeiro dia
No primeiro dia, vários funcionários não conseguiram fazer login.
Adriano estranhou.
Os usuários estavam cadastrados no banco de dados. Ele mesmo havia criado os registros.
Mas um mecanismo de autenticação não é apenas uma tabela com nome, e-mail e senha.
Existem convites, recuperação de acesso, expiração de sessão e armazenamento seguro de credenciais. Existem comportamentos que não aparecem na primeira tela e que Adriano, por nunca ter desenvolvido software, não sabia que precisava especificar.
Ele conversou com o Claude, ajustou o fluxo e resolveu.
Pouco depois, surgiu outro problema.
Alguns usuários conseguiam visualizar informações de outras pessoas.
A autenticação funcionava. O sistema sabia quem havia entrado.
Faltava autorização. O sistema não sabia o que cada usuário poderia acessar.
Adriano conversou novamente com o Claude e resolveu.
Algumas semanas depois, a empresa mudou uma regra financeira.
A mesma regra havia sido escrita em quatro partes diferentes do sistema. Adriano pediu ao agente que fizesse a alteração, mas uma das implementações ficou para trás.
Agora, duas telas apresentavam resultados diferentes para a mesma pergunta.
O código rodava.
O sistema não era confiável.
Código não é sistema
Adriano começou a perceber algo que não aparecia enquanto desenvolvia sozinho:
Escrever código é apenas uma parte da construção de um produto.
Um software precisa de decisões sobre produto, experiência do usuário, arquitetura, dados, segurança e infraestrutura.
Também precisa ser implantado, observado, corrigido e evoluído.
Quando algo quebra, alguém precisa descobrir o que aconteceu.
Quando uma pessoa deixa o projeto, o conhecimento não pode sair junto com ela.
Quando o negócio muda, o sistema precisa conseguir mudar sem que cada alteração vire uma nova cirurgia.
Adriano havia construído uma aplicação.
Agora precisava construir tudo o que manteria aquela aplicação viva.
Nesse momento, Adriano percebe que tem outro problema.
Para continuar construindo o sistema, precisará montar uma equipe.
E uma equipe de produto não nasce apenas com a contratação de dois ou três desenvolvedores.
Adriano precisará encontrar as pessoas certas, avaliar competências que não domina, criar cultura, definir processos, organizar infraestrutura e descobrir quais papéis são necessários.
Enquanto tenta construir o sistema que resolveria seu problema original, começa a montar uma pequena software house dentro da empresa.
Agora ele tem dois negócios para administrar.
O negócio que conhece profundamente e uma operação de tecnologia que ainda está aprendendo a construir.
Foi aí que ele me perguntou:
“Devo montar meu próprio time ou contratar um parceiro?”
Meu conselho foi direto.
Contrate um parceiro
Eu não montaria um time interno do zero agora.
Contrataria um parceiro de tecnologia que estivesse pronto para começar na segunda-feira.
Adriano já tem um problema complexo para resolver. Não faz sentido adicionar, ao mesmo tempo, o desafio de aprender a contratar, organizar e liderar uma operação inteira de tecnologia.
Um parceiro estruturado já reúne as competências necessárias para transformar uma regra de negócio em produto.
Não entrega apenas pessoas que escrevem código.
Ajuda a entender o problema, definir o produto, tomar decisões de arquitetura, pensar na experiência das pessoas, proteger os dados e criar uma forma segura de colocar o sistema em produção.
Enquanto o parceiro cuida da engenharia, Adriano continua fazendo aquilo que ninguém de fora conseguiria fazer por ele: explicar o negócio, tomar decisões e mostrar onde está o verdadeiro diferencial da empresa.
Isso reduz o tempo entre a ideia e o resultado.
Também evita que a empresa use o próprio produto como laboratório para aprender, da maneira mais cara possível, como montar uma equipe de tecnologia.
E o conhecimento não fica com o parceiro?
Essa preocupação é legítima.
Trocar a dependência de um software de prateleira pela dependência de uma software house não resolve o problema.
Por isso, um bom parceiro não pode funcionar como uma caixa-preta.
As decisões precisam ser registradas. O código precisa pertencer ao cliente. O produto deve ter testes, documentação, observabilidade e uma arquitetura que outras pessoas consigam compreender.
A empresa precisa participar da visão e das decisões.
Se, no futuro, fizer sentido montar um time interno, o conhecimento deve poder ser transferido.
O parceiro acelera a construção da capacidade.
Não pode sequestrá-la.
É aqui que entra a Origami Lab.
É exatamente esse tipo de problema que buscamos resolver na Origami Lab.
Entramos quando uma empresa conhece profundamente o próprio negócio, sabe que os softwares de mercado não atendem seu diferencial, mas ainda não possui toda a estrutura necessária para transformar esse conhecimento em um produto sustentável.
A empresa traz o domínio.
Nós entramos com produto, design e engenharia para transformar esse domínio em software.
Não substituímos a visão do empresário. Damos estrutura técnica para que ela saia da cabeça, deixe de depender de planilhas e se transforme em uma capacidade real da empresa.
Com o tempo, essa capacidade pode continuar sendo sustentada pelo parceiro, migrar para um time interno ou funcionar em um modelo híbrido.
A escolha vem depois.
Primeiro, é preciso construir direito.
A dobra
O Victor está certo:
"Compre o que te iguala. Construa o diferencial.”
Minha dobra é esta:
“Você não precisa construir o diferencial sozinho.”
Comprar software significa aceitar parte das regras e dos limites de um fornecedor.
Construir significa assumir responsabilidade pelo que vier depois.
Um parceiro de tecnologia existe para que a empresa assuma essa responsabilidade sem precisar virar uma software house da noite para o dia.
Não precisamos construir tudo.
Precisamos reconhecer qual parte do negócio não pode ser igual à de todos os concorrentes.
E, quando decidirmos construí-la, precisamos escolher quem tem capacidade para transformar aquela diferença em um sistema seguro, sustentável e pronto para evoluir.
Se sua empresa se reconheceu na história do Adriano, me chama.
É justamente esse tipo de problema que resolvemos na Origami Lab.
Compre o que te iguala. Construa o diferencial. E escolha o parceiro certo para construir com você.
E essa foi mais uma dobra de: construir o diferencial sem precisar construir tudo sozinho.
Nos vemos na próxima quinta, às 10:10.
Referências
Victor Couto — Compre o que te iguala. Construa o diferencial.
Ítalo Castro — Todo mundo virou dev?