Treze anos em sistemas de retaguarda bancária antes de fundar o estúdio. Conduz a célula de plataformas e responde por arquitetura.
Construímos software como quem constrói infraestrutura.
Onze anos, um endereço só, uma equipe interna. O método nasce dessa estabilidade: a continuidade do time é o que permite ciclos curtos com responsabilidade longa.
Por que existimos
O Horizonte Grid nasceu em 2015, em uma sala compartilhada na Vila Olímpia, com três engenheiros que vinham de equipes internas de bancos e operadoras logísticas. A motivação inicial era específica: prestar a mesma qualidade de engenharia que entregavam dentro de grandes operações, agora para empresas médias que não tinham capacidade de manter time próprio.
O posicionamento se manteve. Atendemos operações cuja paralisação tem custo mensurável — logística, indústria, saúde, crédito. O que separa um sistema bem feito de um sistema improvisado, nesses contextos, é raramente visível na superfície. Está no contrato de dados, na cobertura de testes, na ordem dos deploys, na capacidade do time interno de continuar mantendo o que entregamos.
Hoje somos dezoito engenheiros e dois sócios operacionais. O critério para crescer continua sendo a capacidade de manter o método sem diluir o time.
Sete posições técnicas que orientam o trabalho.
Princípios são posições que tomamos antes da pressão chegar. Sustentam decisões que parecem pequenas no dia a dia e se acumulam no resultado final.
Código em produção, não documento em pasta.
Diagramas, especificações e roadmaps servem para apoiar a decisão. Nenhum substitui o sistema funcionando com usuários reais.
O time que vende é o time que entrega.
Não há camada comercial intermediária. Quem conversa com o cliente nas primeiras semanas é quem responde pelo projeto até o fim.
Ciclos curtos, escopo recortado.
Recusamos contratos com escopo grande demais para a maturidade atual do cliente. Aceitamos o recorte que cabe em quatro semanas.
Sem subcontratação invisível.
Todo engenheiro alocado em projeto é interno e identificado. Não terceirizamos partes do código para fornecedores que o cliente desconhece.
Documentação operacional é entrega.
Toda transição inclui material para o time interno do cliente assumir, caso decida. Dependência forçada é falha de método.
Tecnologia subordinada ao problema.
Escolhemos linguagens, frameworks e bancos pelo encaixe com o problema do cliente, não pela conveniência de quem desenvolve.
Recusa é parte do trabalho.
Recusamos cerca de um terço das propostas recebidas. Sempre que o método não se sustenta no longo prazo, indicamos outro fornecedor.
Algumas das pessoas que respondem pelo trabalho.
Equipe interna, sem rotação no quadro societário desde 2015. Lista parcial — os engenheiros estão organizados em três células: plataformas, dados e auditoria.
Veio de operação logística internacional. Coordena pipelines analíticos e modelos de risco em contratos de longo prazo.
Responsável pela camada de eventos que atende contratos industriais. Atuação técnica em sistemas SAP e MES.
Desenha interfaces para uso intenso e prolongado. Trabalha próxima aos usuários finais durante a fase de leitura.
Conduz relatórios de due diligence técnica. Atuação anterior em consultoria estratégica e governança de TI.
Cuida da continuidade entre os ciclos de quatro semanas. Ponto de contato administrativo para os clientes ativos.
Não construímos software para reuniões de diretoria. Construímos para o turno da madrugada — quando ninguém está olhando, mas o pedido precisa ser processado e o relatório precisa estar correto na manhã seguinte. É um padrão diferente.
Se há sintonia com o método, vale uma primeira conversa.
A primeira conversa é com um dos sócios e dura cerca de quarenta minutos. Não há proposta sem antes uma leitura preliminar da operação.
Agendar conversa