Plataforma de roteirização para uma transportadora regional do Sul
Substituiu uma planilha de quase mil linhas e três sistemas auxiliares. Reduziu o ciclo de despacho de 4 horas para 35 minutos no pico.
Estúdio de engenharia · Fundado em 2014 · São Paulo
Plataformas, sistemas internos e produtos digitais construídos com método. Para empresas que tratam software como ofício, e não como entrega rápida.
Cronovetor©
Software bem construído resiste ao tempo. Defendemos a engenharia paciente — a que documenta, testa, mede e revisa antes de seguir adiante.
— Manifesto do estúdio, capítulo I
O método · Seis etapas
Como um projeto se desdobra conosco
Trabalhamos em ciclos definidos, com entregas tangíveis em cada etapa. Nenhum cliente precisa adivinhar o que está sendo feito ou quando terminará.
-
I.
Descoberta e diagnóstico
Quatro a seis sessões com pessoas que usam o sistema atual ou que vão usá-lo. Mapeamos restrições, processos manuais que viraram norma e o que realmente trava o trabalho. Saímos com um documento legível, não um deck de slides.
Entrega · Diagnóstico técnico e de processo · 2 a 3 semanas -
II.
Arquitetura
Antes de qualquer linha de código de produção, desenhamos as fronteiras: serviços, integrações, modelo de dados, decisões de infraestrutura. Cada escolha é registrada com sua justificativa, para que três anos depois alguém ainda saiba por que foi feita.
Entrega · Documento de arquitetura e ADRs · 2 semanas -
III.
Construção
Ciclos de duas semanas com revisão sempre na sexta-feira. Código revisado em par antes de entrar em produção. Cobertura de testes nos pontos críticos, não em todo lugar — disciplina, não dogma.
Entrega · Releases quinzenais · 3 a 9 meses -
IV.
Validação
Testes de integração e cargas reais antes da entrada em produção. Auditoria de segurança feita por engenheiro externo ao projeto. Plano de recuperação documentado e treinado com o time interno.
Entrega · Relatório de validação assinado · 2 semanas -
V.
Lançamento
Implantação gradual, com rollback testado. Acompanhamento das primeiras seis semanas em regime intensivo: telemetria revisada diariamente, ajustes finos antes que virem dívida.
Entrega · Sistema em produção, métricas estáveis · 6 semanas -
VI.
Continuidade
Optamos por permanecer envolvidos depois do lançamento, em escala reduzida. Atualizações de dependências, ajustes de capacidade, evolução do produto conforme o uso real revela o que importa.
Entrega · Suporte contínuo opcional · 12 meses ou mais
Trabalhos selecionados
Sistemas que continuam de pé
Uma amostra dos projetos que tornamos públicos. Os clientes nominais aparecem com permissão; os demais permanecem como descrições técnicas.
Prontuário integrado para rede de clínicas em São Paulo
Migração de quatro sistemas legados para uma base única, com retenção dos dados históricos e auditoria conforme exigências da LGPD.
Núcleo de processamento de pagamentos para uma fintech B2B
Reescrita do motor de conciliação e arquitetura de eventos. O sistema atende quatro mil transações por minuto em horário de pico.
Sistema de chão de fábrica para uma indústria metalúrgica em Joinville
Coleta de telemetria em 38 estações de trabalho, painéis em tempo real para os encarregados e relatórios mensais consolidados para a diretoria.
2014
Ano de fundação do estúdio em São Paulo
62
Projetos concluídos para empresas brasileiras e portuguesas
11
Engenheiros e arquitetas em regime permanente
94%
Dos clientes que retornam para um segundo projeto
Princípios do estúdio
O que defendemos, em ordem de prioridade
Há decisões que tomamos antes de cada projeto começar. Estão escritas, não negociadas em reunião.
I —
Código legível antes de código curto
Outros engenheiros vão ler o que escrevemos. Frequentemente serão pessoas do time interno do cliente, três anos depois. Escrevemos para essa pessoa.
II —
Documentação no repositório, não em wiki
A documentação vive ao lado do código que descreve. Quando o código muda, a documentação muda no mesmo commit. Wikis externas envelhecem rápido demais.
III —
Decisões registradas com justificativa
Toda escolha arquitetural relevante vira um ADR — Architecture Decision Record. O contexto, as alternativas consideradas e a razão da escolha ficam disponíveis para consulta.
IV —
Telemetria antes de funcionalidade
Não entregamos uma feature nova sem antes saber como mediremos seu impacto. Se não dá para medir, não dá para defender.
V —
Transferência de conhecimento contínua
O time do cliente acompanha as decisões desde o primeiro dia. Ao final do projeto, o conhecimento já está com eles — não num documento de hand-off feito às pressas.
VI —
Conservadorismo na infraestrutura
Tecnologia nova exige razão forte. Preferimos PostgreSQL e bibliotecas com dez anos de uso a frameworks lançados na semana passada — a menos que o caso justifique.
✦ ❋ ✦