Engenharia de produto para sistemas em que o erro custa caro.
Desenvolvimento de software sob medida: plataformas B2B, web e mobile, sistemas críticos e modernização de legado, em Rust, Python, Ruby e TypeScript. Fazemos engenharia de produto desde 2008, para software que precisa ficar de pé sob carga real.
Três frentes de engenharia
Plataformas B2B
Produtos digitais completos, da interface à infraestrutura na nuvem (AWS ou GCP), na web e no mobile: nativo em Swift e Kotlin ou multiplataforma em React Native e Flutter, conforme o produto. Desempenho é critério de aceite, com meta de carregamento (LCP) combinada por projeto e medida nas visitas reais, e as páginas nascem preparadas para buscadores (SEO técnico).
Sistemas de alta exigência
Backends em Rust onde tempo de resposta previsível e erros barrados antes de ir ao ar pesam mais do que a velocidade de entrega: motores de decisão, processamento de eventos e APIs de missão crítica. Num case medido, com a etapa gargalo reescrita de Python para Rust, um pipeline inteiro passou de cerca de 4 horas para cerca de 40 segundos no mesmo dataset (metodologia em Cases).
Modernização de legado
Substituímos o sistema antigo por partes (padrão strangler fig), sem parar a operação e sem exigir troca de banco: integramos o que o legado já usa (Oracle, SQL Server). O ponto de partida é o mapa do código feito pelo CodeSense, nosso motor próprio de contexto.
Por onde começar
Com um produto a construir
Produto completo (interface, backend e infraestrutura) ou um módulo isolado, integrado ao seu time. Arquitetura e especificação vêm antes da primeira linha.
Com um projeto em curso
Começamos por uma auditoria curta de arquitetura e dívida técnica, entregamos um plano com a ordem de ataque e assumimos a frente combinada, sem refazer o que funciona.
Com um legado a modernizar
Não propomos reescrita total nem parada do seu roadmap. Se a auditoria mostrar que o legado aguenta mais dois anos com intervenções pontuais, é isso que recomendamos.
Em qualquer caso, o projeto tem escopo fechado (você contrata o resultado), com engajamentos a partir de cerca de 4 semanas. Na entrega, você escolhe: operação contínua com a Kazap ou transferência total para o seu time, com treinamento.
Como modernizamos sem parar a operação
Auditoria de arquitetura e dívida técnica
Mapa do sistema feito com o CodeSense (dependências, modelo de dados, áreas de risco) e uma ordem de ataque que pesa risco e valor.
Retrato dos fluxos críticos (golden master)
Antes de mexer no código, registramos o comportamento atual (o que entra e o que sai), e uma pessoa revisa esse primeiro retrato. A partir daí, qualquer mudança de comportamento dispara um alerta: se foi acidente, corrige-se; se foi de propósito, aprova-se conscientemente. Para proteger esses fluxos, não é preciso entender todo o código antes: basta registrar o que ele faz hoje.
Substituição por fatias
Cada funcionalidade do legado é levada para o sistema novo, atrás de uma camada que decide para onde vai cada requisição. O sistema antigo encolhe parte a parte.
Tráfego espelhado (shadow traffic)
Antes de atender usuários, o componente novo recebe uma cópia do tráfego de produção, e as respostas dele são comparadas com as do legado. Nas fatias que gravam dados ou disparam efeitos (cobrança, e-mail), as gravações vão para um banco sombra ou os efeitos são neutralizados. Cada diferença é investigada antes da virada.
Volta automática, desligamento só com prova
Cada etapa tem um critério objetivo de saúde: se ele falha, o tráfego volta sozinho para a versão anterior (rollback). O sistema antigo só é desligado quando o novo provou, em produção e com métricas, que aguenta.
O que toda entrega inclui
Verificação antes do merge
Toda mudança passa pela esteira de integração (CI) e por uma revisão numa sessão separada da autoria, que tenta quebrar o que foi feito (revisão adversarial). O que falha volta para correção.
Testes que pegariam um bug
Os testes saem da especificação, e não do código gerado pela IA; nos caminhos críticos, mutações de propósito verificam se a bateria percebe (mutation testing).
Capacidade de operar
Observabilidade (logs, métricas e rastreamento), manuais de operação (runbooks) escritos por quem construiu e cada decisão relevante registrada com o porquê (ADR).
Todo projeto usa o método da Squad Amplificada (o método, não o formato de contratação): codificação assistida por agente de IA, hoje com Claude Code e também Codex e similares, com a senioridade no comando e uma pessoa sênior assinando a entrega.
Perguntas frequentes
Qual a diferença para a Squad Amplificada?
Na Engenharia de Produto, o escopo é fechado e você contrata o resultado. Na Squad, você contrata capacidade contínua: um time alocado que avança no seu roadmap. A Kazap indica o formato certo na primeira conversa.
Por que Rust?
Escolhemos Rust para o backend quando pesam latência previsível, mais classes de erro pegas já na compilação (segurança de memória e ausência de corridas de dados, as data races) e custo de máquina em alto volume: motores de decisão, processamento de eventos, APIs de missão crítica. Quando o problema não pede isso, usamos a linguagem mais adequada ao caso (Python, Ruby, TypeScript) e escolhemos o framework por projeto. Se o backend não precisa de Rust, dizemos.
Vocês fazem app iOS e Android?
Sim, dentro dos projetos de engenharia: nativo em Swift (iOS) e Kotlin (Android), ou multiplataforma em React Native e Flutter, conforme o perfil do produto, com o mesmo padrão de qualidade do resto.
Como garantem que a IA não quebra o que já funciona?
Em camadas. Antes de qualquer mudança, registramos o comportamento atual dos fluxos críticos, e toda mudança nesses fluxos é comparada com esse registro. A revisão e a esteira de testes protegem o caminho até o merge. E, em modernização, o sistema novo processa o mesmo tráfego ao lado do antigo antes de assumir. Ninguém dá garantia absoluta, mas a mudança silenciosa de comportamento é justamente o risco que esse desenho ataca.
Como confiar em testes que a própria IA escreveu?
Não confiando por padrão. Teste escrito a partir do código que o próprio agente gerou só confirma que o código faz o que faz. Por isso os testes saem da especificação, escrita antes do código; a revisão adversarial examina os testes como examina o código; e, nos caminhos críticos, mutações de propósito verificam se a bateria percebe (mutation testing).
Quem opera o sistema depois da entrega?
Você escolhe. Nuvem e operação fazem parte da entrega: AWS e GCP, containers e Kubernetes, observabilidade desde o primeiro dia e manuais de operação (runbooks). Depois, a operação segue com a Kazap ou passa inteira para o seu time, com treinamento. Nível de serviço, propriedade do código e titularidade das contas de nuvem são termos de contrato, combinados na proposta.
O mapa do CodeSense tira o código do meu sistema do meu controle?
Não. O CodeSense, que mapeia o sistema antes de qualquer mudança, roda na sua infraestrutura (self-hosted), com filtro de dados sensíveis (DLP para CPF, CNPJ e segredos), e o índice fica num ambiente que você controla. Para inferência e embeddings, trechos de código passam pela API do provedor do modelo, sob os termos que vocês têm com ele.