— Manifesto
O software não é uma corrida de curto prazo.
É a infraestrutura silenciosa que carrega uma empresa por uma década, ou que a derruba em três anos. Construímos para a primeira hipótese.
Ensaio — 01
A maior parte do trabalho de tecnologia, hoje, consiste em conectar peças prontas. Isso resolve metade dos problemas — e cria a outra metade.
Nos últimos dez anos, a engenharia de software brasileira aprendeu a montar produtos a partir de blocos: bancos gerenciados, filas, ferramentas no-code, integrações por API. É produtivo no primeiro ano. No terceiro, a fatura de fornecedores cresce mais rápido que a receita, ninguém na equipe entende o caminho de um pedido do clique até o banco, e qualquer alteração no fluxo principal exige duas semanas e três reuniões.
A Lógica Pulsar nasceu da convicção de que existe espaço, novamente, para sistemas projetados com intenção. Não recusamos a nuvem nem reescrevemos tudo do zero. Apenas tratamos cada decisão de arquitetura como uma decisão de longo prazo: que custo isto cobra dentro de cinco anos, quem precisará entender este módulo daqui a três trocas de equipe, qual é o caminho de saída se o fornecedor escolhido encerrar o serviço.
Nosso trabalho começa antes do primeiro commit. Sentamos com a operação, lemos os contratos com fornecedores, mapeamos os processos manuais que ninguém quis automatizar porque o caso de uso parecia raro. Em quase todas as auditorias que conduzimos, encontramos entre quatro e sete pontos onde a arquitetura atual cobra um imposto invisível — em produtividade, em risco regulatório, em conta de servidor.
Daí o nome. Pulsar é o ritmo periódico que orienta. Lógica é a parte que sustenta o ritmo. Juntos, descrevem o que entregamos: sistemas que pulsam de forma legível, em vez de caixas pretas que ninguém ousa abrir.
Um sistema bem desenhado parece banal de fora — e é exatamente esse o trabalho.— Diretrizes internas, Lógica Pulsar
Princípios — 04
Cada projeto começa com uma fase de leitura: contratos com fornecedores, logs de incidentes, diagramas existentes, conversas com quem opera o sistema diariamente. Costuma durar entre duas e quatro semanas. É a parte do trabalho que rende menos linhas, e que melhor decide o resultado.
Escolhas grandes — fornecedor de banco, runtime de aplicação, camada de mensageria — sempre vêm com um plano de saída documentado. Nenhuma dependência crítica entra no sistema sem que o custo de substituição esteja escrito.
Trabalhamos em ciclos de duas semanas com entregas verificáveis. Sem demonstrações teatrais, sem janelas longas sem informação. A operação interna do cliente acompanha o avanço por métricas que importam para ela, não para nós.
Cada decisão arquitetural fica registrada na própria base de código, em texto legível por quem chegar daqui a três anos. Quando saímos, a equipe interna lê o sistema sem precisar de nós. É a única medida de sucesso que importa no longo prazo.
Estúdio — Em números
Escrevemos para a equipe que herdará o código, não para a auditoria de portfólio.— Sobre o ofício
Trabalhos recentes — 03
Substituímos uma cadeia de planilhas e três SaaS por um motor próprio. O tempo de geração de rota caiu de 47 para 4 minutos.
Engenharia da camada de fechamento diário, hoje processando 1,8 milhão de operações sem intervenção manual.
Quatro sistemas legados unificados em um só painel. Auditoria de chão de fábrica reduzida de 9 para 2 dias.
Apresente o contexto, ouvimos antes de propor. Sem material institucional, sem orçamento na primeira reunião — apenas leitura cuidadosa do problema.
Iniciar conversa