Quatro frentes, uma forma de trabalhar.

Desenvolvimento de Produto

Tem um produto para pôr de pé e não tem meses para montar uma equipa — nem margem para errar a fundação e descobri-lo no lançamento.

Engenharia ponta a ponta, do zero: uma descoberta curta para cortar âmbito, a primeira fatia em produção em semanas e o produto a evoluir em ciclos a partir daí. Sem big bang, sem protótipo que tem de ser deitado fora depois.

• 01Âmbito fatiado, com a primeira entrega definida no papel
• 02Aplicação em produção, com CI/CD e ambientes separados
• 03API e modelo de dados documentados
• 04Observabilidade e alertas desde a primeira semana
• 05Repositório, nuvem e domínios em nome da sua empresa

• Em quanto tempo vejo a primeira versão no ar?+

  Entre quatro e oito semanas para a primeira fatia útil, consoante o âmbito cortado na descoberta. Não é protótipo: é código em produção, com deploy e monitorização.
• É possível trabalhar em conjunto com a minha equipa interna?+

  Sim, e é o formato que melhor resulta. A equipa interna entra no mesmo repositório e no mesmo ritual; a transferência de conhecimento acontece durante o projecto, não numa reunião no fim.
• De quem é o código no fim?+

  Seu. Repositório, contas de nuvem e domínios ficam em nome da sua empresa desde o primeiro dia.

Engenharia de Plataforma

Deploy que encrava, incidente que ninguém sabe quem atende e uma factura de nuvem a crescer mais depressa do que o produto.

Medir antes de mexer. Primeiro os números — tempo de deploy, taxa de falha, tempo de recuperação, custo por ambiente — depois as mudanças que movem esses números, uma de cada vez, a começar pelas que reduzem risco sem tocar no produto.

• 01Pipeline de deploy automatizado, igual em todos os ambientes
• 02Infra-estrutura como código, versionada
• 03Painéis e alertas com dono definido e acção escrita
• 04Runbook de incidente e rollback ensaiado
• 05Teste de restore de backup a correr no calendário
• 06Revisão de custo por ambiente e por serviço

• É possível fazer isto sem parar as entregas?+

  É. A ordem é sempre a mesma: primeiro o que reduz risco sem tocar no produto — backup testado, alerta com dono, rollback ensaiado —, depois a infra-estrutura por baixo.
• Ficam a operar a plataforma depois?+

  Só se quiser. O padrão é entregar com runbook e formar a equipa. Suporte contínuo é um contrato à parte, nunca uma dependência criada de propósito.
• Em quanto tempo aparece o primeiro ganho?+

  As duas primeiras semanas devolvem normalmente um teste de restore a funcionar e os alertas com dono — que é onde mora o risco a sério.

• 45 minutos, 460 milhões de dólares: quando falta governança de tecnologia20/09/2026

Sistemas de IA

A demo encanta a direcção e desfaz-se na primeira semana de produção: latência fora do acordado, factura de tokens sem explicação e resposta que ninguém consegue conferir.

Tratar a IA como sistema, não como magia: orçamento de latência por etapa, contexto recuperado com a fonte citada, avaliação contra perguntas reais e custo medido por funcionalidade — não por impressão.

• 01Ingestão, chunking e embedding com reindexação incremental
• 02Pesquisa vectorial com filtro e recall medido
• 03Conjunto de avaliação com perguntas reais e nota por versão
• 04Painel de custo por funcionalidade, com cache verificada
• 05Caminho de fallback determinístico para quando o modelo for abaixo

• Os meus dados vão treinar o modelo?+

  Não. Os documentos ficam na sua base de dados e as chamadas seguem por contratos que não usam o seu conteúdo para treino. É uma decisão de arquitectura e de contrato, e fica escrita no projecto.
• Quanto custa manter isto a correr por mês?+

  Depende do volume, mas torna-se previsível quando é medido. Indexar um corpus de algumas centenas de trechos custa cêntimos; a despesa real está nas chamadas de geração — e é aí que a cache de prompt e o tamanho de contexto derrubam a conta.
• É possível correr com modelo aberto, na minha nuvem?+

  É. A arquitectura separa pesquisa de geração, por isso trocar o modelo passa a ser uma decisão de custo e qualidade, não uma reescrita.

• RAG em produção: o que muda quando existe SLA20/09/2026

Modernização de Legado

Um sistema em que ninguém quer tocar, que só uma pessoa percebe a sério, e que segura todo o resto do negócio.

Nada de reescritas de dois anos. Mapear o que existe, cercar o comportamento actual com testes e migrar por fatias — com o sistema antigo no ar até à última delas, e rota de regresso em cada etapa.

• 01Mapa de dependências, riscos e pontos de falha única
• 02Testes de caracterização sobre o comportamento actual
• 03Plano de fatias, com ordem e critério de corte
• 04Migração incremental, com rota de regresso em cada etapa
• 05Documentação viva do que migrou e do que ficou

• É preciso parar a operação?+

  Não. Cada fatia entra com o sistema antigo ainda de pé; a viragem só acontece quando a fatia nova já provou que responde igual.
• E se não existir documentação nenhuma?+

  É o caso mais comum. Os testes de caracterização passam a ser a documentação: registam o que o sistema faz hoje, incluindo o que faz mal e de que o negócio já depende.
• Quanto tempo demora?+

  A auditoria e o plano de fatias demoram duas a três semanas. A migração mede-se em fatias entregues, não num prazo único — e pode parar entre uma e outra.