Especialização · Software por medida

Um sistema construído para a forma como a sua organização trabalha, não para o caso geral.

Construímos sistemas de raiz, quando nenhum produto no mercado se adequa: plataformas com várias aplicações e uma base de dados comum, conectores para sistemas que não têm API, pipelines que lêem documentos e movimentos de dinheiro, e programas cujo resultado não é um ecrã, mas um dossier de fabrico. No final entregamos o repositório, o documento de colocação em funcionamento e os acessos.

Fale sobre um projeto

Já construídoEscolhi quatro sistemas próprios de disciplinas diferentes, precisamente para que não parecessem quatro variantes do mesmo site, e executei hoje os testes de cada um. Um monorepo com 3 aplicações e 12 pacotes, 486 ficheiros TypeScript e 68 ficheiros de teste, 151 commits, árvore de trabalho limpa. Um sistema de consulta de dois portais B2B sem API pública: 38 testes aprovados em 0,52 s, com respostas reais guardadas como fixtures. Uma pipeline que lê notificações bancárias de e-mail e PDF e as escreve no Postgres com deduplicação por fingerprint. E um gerador de documentação de engenharia, em Python, com 44 testes aprovados em 0,50 s. Os números são das minhas execuções de 6 de setembro de 2026, não de READMEs.

«Por medida» significa que o sistema é escrito de acordo com a forma como as suas pessoas já trabalham, e não o contrário. Tem um custo que é honesto dizer antes: alguém tem de o manter, e esse alguém somos nós ou a sua equipa. Por isso, a primeira pergunta que lhe fazemos não é o que quer construir, mas se existe um produto que já faça 80% do trabalho. Se existir, dizemo-lo, mesmo que isso signifique que não nos dá o trabalho. O que fica depois dessa pergunta — a parte que não se compra — é exatamente o que construímos bem.

A amplitude vê-se mais claramente em quatro sistemas diferentes do que numa lista de tecnologias. O primeiro é uma plataforma para uma instituição de espetáculos: um monorepo com três aplicações (site público, gabinete administrativo, API) e doze pacotes comuns — bilhetes, comércio, conteúdo, notificações, reembolsos, segurança. O segundo consulta, a pedido, os portais B2B de alguns tour operators que não publicam qualquer API: autenticação programática, regresso ao login quando a sessão expira, e um analisador testado em respostas reais capturadas em ficheiros. O terceiro lê notificações bancárias de e-mail e extratos em PDF e coloca-os em Postgres. O quarto não tem ecrã nenhum: é o programa que gera o modelo, a lista de materiais e os desenhos de uma máquina industrial.

O que sustenta um sistema destes não é a pilha, mas as regras escritas antes do primeiro ecrã. Na plataforma para a instituição de espetáculos, o contrato de implementação fixa em texto coisas que, de outra forma, se negoceiam em cada reunião: o dinheiro é mantido em unidades menores inteiras, com a moeda ao lado; a disponibilidade de um lugar é dada apenas por uma reserva durável na base de dados, nunca pela memória intermédia; as ordens críticas têm chaves de idempotência; os caminhos P0 e P1 falham fechado, não aberto; os dados do cartão nunca são armazenados. Estas regras escrevem-se no início porque, escritas no fim, significariam reescrever o sistema.

No final, entregam-se três coisas, não uma: o repositório com todo o seu histórico, o documento que diz como o pôr em funcionamento num servidor vazio, e os acessos. Sob o nosso diretório de projetos existem 150 repositórios git, 103 ficheiros README e 19 documentos de colocação em funcionamento ou de entrega — contados hoje, não estimados. A regra de propriedade escrevemo-la no contrato antes do arranque e é simples: o código escrito especialmente para você é seu, as bibliotecas de terceiros permanecem sob a respetiva licença, e os nossos componentes reutilizáveis e os nossos produtos são licenciados, não cedidos. Se uma parte do trabalho se resolve melhor com um produto nosso, dizemo-lo exatamente assim, para que saiba desde o início o que compra e o que recebe.

Qué incluye

El trabajo, por componentes

Escrevemos as regras do domínio antes do primeiro ecrã

Um contrato de implementação, em texto, que fixa o vocabulário e os invariantes: o que significa um lugar reservado, o que significa um pagamento recebido, o que falha fechado quando um serviço não responde. Na plataforma para a instituição de espetáculos, as regras são explícitas — dinheiro em unidades menores inteiras mais a moeda, disponibilidade apenas a partir de reservas duráveis na base de dados, chaves de idempotência nas ordens críticas, memória intermédia nunca como fonte de verdade para o stock, dados do cartão nunca armazenados. São regras que se verificam no código, não princípios.

Construímos o núcleo com testes que correm sem o sistema vivo

As respostas reais dos sistemas externos são guardadas como fixtures e o analisador é testado nelas, não no portal que pode estar em baixo exatamente no dia em que você trabalha. No sistema de consulta de portais de voos, a suite executa em 0,52 segundos e passa integralmente; os testes que realmente tocam nos portais são marcados separadamente e têm de ser pedidos explicitamente. A mesma separação existe em todos os quatro sistemas: o que pode ser verificado na bancada é verificado na bancada.

Entregamos o repositório, a colocação em funcionamento e os acessos

Não um ficheiro zip. O repositório com o histórico dos commits, um documento que descreve como levantar o sistema numa máquina vazia — base de dados, variáveis de ambiente, serviço de sistema, servidor web à frente — e os acessos que o tornam seu. Sob o nosso diretório de projetos existem hoje 150 repositórios git, 103 README e 19 documentos do tipo DEPLOY ou HANDOVER; esta forma de entrega é o hábito, não a exceção.

Quando o sistema do outro não tem API, dizemos que risco você assume

Os portais B2B que consultamos não publicam interface programática, por isso a autenticação faz-se como a de um utilizador, com cookie de sessão e chave de ligação, e é refeita automaticamente na expiração. O risco está escrito no README do projeto, não descoberto mais tarde: a autenticação programática é uma zona cinzenta face às condições de utilização do portal, e para um volume de produção intenso a solução correta é pedir ao operador a sua API oficial. Um cliente tem o direito de saber isso antes de assinar, não depois.

Os documentos entram uma única vez, mesmo que os leamos dez vezes

Cada transação extraída de uma notificação bancária ou de um extrato PDF recebe um identificador externo calculado como impressão digital SHA-256 sobre os seus campos, e a inserção em Postgres faz-se com `ON CONFLICT (external_id) DO NOTHING`. A consequência prática: a caixa de correio pode ser relida quantas vezes você quiser, e o saldo não duplica. Sem esta regra, qualquer pipeline de ingestão acaba por produzir duplicados, ou seja, um problema de contabilidade.

A classificação com modelo faz-se por ferramentas, não por texto livre

O modelo não escreve uma frase que depois adivinhamos: recebe sete ferramentas — pagamento do cliente, salário, imposto, pagamento a credor, despesa operacional, desconhecido — e tem de escolher uma, com uma pontuação de confiança entre 0 e 1. Para a correspondência aproximada dos nomes da contraparte existe uma reserva separada, com base na semelhança de vetores. «Desconhecido» é uma saída legítima, com motivo, não uma falha escondida.

Às vezes, o resultado não é um ecrã, mas um dossier

Um sistema próprio em Python gera o modelo tridimensional de uma máquina industrial, a lista de materiais com estado de libertação em cada posição, o plano de verificação, o esquema de cabos e as folhas PDF — a partir de um único comando, para que nada do pacote possa ficar atrás do modelo. Tem 44 testes que passam em meio segundo e que verificam regras de engenharia, não apenas código: que o domínio ativo é exatamente um metro cúbico, que nenhuma posição da lista de materiais fica sem linha de verificação, que a máquina nunca extruda em repouso.

A medição contínua é outra disciplina diferente da consulta a pedido

Um sistema próprio capta simultaneamente várias estações de rádio com `ffmpeg`, transcreve localmente com um modelo open-source, depois procura anúncios com uma pontuação transparente por grupos de sinais em romeno e russo, com limiar configurável, e agrupa o mesmo anúncio transmitido em estações diferentes através de uma impressão digital de áudio do tipo chromaprint — porque as transcrições divergem, mas o som é idêntico. Tem 81 testes que passam em 1,14 segundos. Um sistema que funciona sem supervisão precisa de contadores de cobertura, retentativas com lease de tarefas e um autoteste, caso contrário fica em silêncio quando avaria.

Também dizemos o que não construímos

Não construímos de raiz o que se resolve com um produto existente, nosso ou de outra pessoa, só porque o trabalho seria maior. Não assumimos sistemas que não possamos executar localmente, com dados de teste, até ao fim da primeira etapa. E não iniciamos um sistema que depende de um fornecedor externo antes de verificarmos que porta pública esse fornecedor tem — essa verificação é a primeira, não a última.

Qué aspecto tiene

El recorrido, paso a paso.

Delimitamos o domínio e escrevemos as regras

Uma etapa de leitura de sistemas e de conversa com as pessoas que fazem o trabalho hoje, concluída com um documento curto com o vocabulário, as invariantes e o que falha em modo fechado. Entregamos este documento mesmo que não se chegue à construção — é útil mesmo sem nós. Nele entra também a lista de sistemas externos de que o trabalho depende e a verificação de que gate público tem cada um, porque é daí que vêm as surpresas.

Construímos o núcleo, com os seus testes, antes dos ecrãs

As regras do domínio, os modelos de dados, os analisadores, os cálculos — além dos testes que correm sem os sistemas vivos, sobre fixtures capturadas de respostas reais. Entregamos a suite e o seu resultado, com o comando de execução, para que a possa executar. Um núcleo que não pode ser testado sem o ambiente de produção é um núcleo que não podemos reparar rapidamente mais tarde.

Colocamos a interface e as integrações sobre o núcleo

O gabinete administrativo, os ecrãs públicos, os pontos de entrada para outros sistemas. Aqui ligam-se os fornecedores externos, cada um com um adaptador próprio e com uma variante de simulação, para que o sistema possa ser executado integralmente sem contas reais. Entregamos também o modo de execução local, com base de dados e serviços arrancados a partir de contentores.

Pomos em funcionamento e entregamos

Instalação na infraestrutura acordada, serviço de sistema, servidor web à frente, registos e a sua rotação, autoteste. Depois a entrega: repositório, documento de colocação em funcionamento escrito para uma máquina vazia, acessos, e uma revisão do que falta fazer. O que não chegou a entrar no trabalho escreve-se como lista, não fica por dizer.

Três passos e a sua ordem, que é metade do trabalho. Primeiro, as regras do domínio escritas no texto — o que significa um lugar reservado, como se guarda o dinheiro, o que fica fechado quando um serviço se cala. Depois, o núcleo com os seus testes, que correm em respostas reais guardadas como fixtures, sem os sistemas vivos. Por fim, a colocação em funcionamento e a entrega: depósito, o documento para uma máquina vazia, acessos. A seta para trás do passo três ao passo um é real: o que se descobre na colocação em funcionamento muda as regras, não fica escondido debaixo delas.

Os dados

Qué tocamos, dónde están y cuánto se quedan

Las preguntas que hace cualquiera que tenga un delegado de protección de datos — hechas aquí antes de que las haga él.

Onde corre e quem guarda a chave: O sistema corre na infraestrutura acordada por escrito no início: o seu servidor, um servidor administrado por nós, ou um fornecedor de alojamento escolhido em conjunto. Os quatro sistemas acima correm de forma diferente entre si — um como serviço de sistema atrás de um servidor web, um a partir de contentores, um como processo agendado numa máquina local, um apenas por comando, na estação de trabalho. A escolha é feita a partir das restrições dos dados, não do hábito.
As credenciais não ficam no código e, quando possível, também não ficam no disco: As palavras-passe e as chaves são lidas de variáveis de ambiente, e o ficheiro que as contém fica restrito ao utilizador atual. Num conector para um sistema externo, o token de sessão é mantido apenas em memória e é renovado no fim da validade ou ao primeiro recusado — a palavra-passe e o token não são escritos em nenhum ficheiro. A regra é verificada na revisão: uma chave que chega ao repositório é um incidente, não uma falha.
Dados que entram a partir de documentos: Quando o sistema lê e-mails ou PDFs, toca em dados reais de negócio: montantes, datas do calendário, nomes da contraparte, números de conta. São armazenados na base de dados do beneficiário, com um identificador próprio, que não pode repetir-se, por registo, e pode ser reconstituído a partir da origem. O que segue para um modelo externo, se for usado um, é a descrição da transação — não o documento completo e não o anexo.
O que se mantém e por quanto tempo: O prazo de retenção é definido por tipo de dado, não globalmente, e é escrito antes da entrada em funcionamento: registos de negócio segundo as obrigações legais do beneficiário, registos técnicos numa janela curta, ficheiros intermédios — capturas áudio, anexos descarregados — com limpeza automática. Um sistema que não tem política de eliminação acaba, em seis meses, por ser um risco maior do que o problema que resolvia.
O que fica connosco após a entrega: Após a entrega, o nosso acesso aos seus sistemas existe apenas se houver um contrato de manutenção que o exija, e é retirado quando esse contrato termina. As cópias de trabalho nas nossas estações são eliminadas a pedido. O que mantemos em qualquer caso são os componentes genéricos que escrevemos e que não contêm os seus dados — e esses declaramo-los desde o início, para que não haja uma surpresa no fim.

Un caso

Um sistema de interrogação para dois portais que não têm qualquer API

A situação

Uma agência de viagens precisava, a pedido, da disponibilidade de lugares e das tarifas em voos charter nos portais B2B de dois operadores turísticos. Os portais foram pensados para olhos humanos: faz-se login, procura-se, lê-se uma tabela. Não existe interface programática publicada, e a informação era recolhida manualmente, várias vezes por dia, por uma pessoa.

Qué construimos

Escrevi um cliente que se autentica programaticamente e refaz a sua sessão sozinho quando expira, um analisador que transforma as respostas em objetos e uma camada de identificadores para aeroportos, onde o código é composto por cidade e porto, e alguns pedidos exigem as duas partes separadamente. Por cima disso: um comando de linha que devolve um percurso completo com disponibilidade e preço, um modo de pedidos em lote com pausas entre eles para não bloquear a conta, e dois pontos de entrada JSON para o caso de outra plataforma querer consumir o resultado. O analisador é testado com respostas reais, guardadas como fixturas no repositório, e os testes que realmente atingem os portais são marcados separadamente e não correm por defeito.

Qué salió

A suíte passa na íntegra: 38 verificações em 0,52 segundos, sem tocar nos portais. Um pedido devolve, numa única resposta, a disponibilidade nas quatro estados que o portal usa e a tarifa com classe e bagagem, na moeda pedida. O resultado pode ser consumido pela linha de comando, como JSON, ou pelos dois pontos de entrada HTTP.

Qué no dice el caso

A autenticação programática continua a ser uma zona cinzenta face aos termos de utilização dos portais, e isso está escrito no README do projeto, não descoberto após a entrega. Para um volume de produção intenso, a nossa recomendação é explícita: deve ser pedido o API oficial aos operadores. O sistema faz pedidos pontuais e faz pausas entre eles precisamente para não se tornar uma ferramenta de extração em massa.

Perguntas

Lo que nos pregunta la gente antes de llamar

Porque é que não há nenhum preço nesta página?

Porque não o poderíamos escrever com honestidade. O esforço de um sistema à medida depende de três coisas que não sabemos antes de olhar: quantos sistemas externos têm de ser acedidos e se algum tem API, quantas regras de negócio já estão escritas algures e quantas têm de ser descobertas junto das pessoas, e quem mantém o sistema em funcionamento após a entrega. Um número dado antes de ver o sistema é um palpite com fatura. O que podemos fazer rapidamente é a primeira etapa — ler, delimitar, escrever as regras — que é estimada corretamente e continua útil mesmo que fique por aí.

Quem fica com o código no final?

O código escrito especialmente para si é seu, incluindo o repositório e o histórico. As bibliotecas de terceiros continuam sob as suas licenças — não as podemos ceder a si, porque não são nossas. Os nossos componentes reutilizáveis e os nossos produtos existentes são licenciados para utilização, não são transferidos; se o seu trabalho se apoiar num deles, dizemos-lho na proposta escrita, antes do início, não na última reunião.

O que acontece se quisermos continuar com outra pessoa?

A entrega tem de tornar isso possível sem nós, caso contrário não foi uma entrega. Por isso, o documento de entrada em funcionamento é escrito para uma máquina vazia e não pressupõe nada da nossa parte, e os testes ficam no repositório para que a próxima equipa saiba o que se parte quando altera. O que não podemos prometer é que um sistema complexo seja assumido sem esforço — podemos prometer apenas que não lhe falta nada do que é preciso para ser assumido.

Posso ver um sistema construído por vocês, para avaliar a qualidade?

Parcialmente, e é correto dizermos onde para. Os sistemas construídos para clientes não são nossos para os mostrarmos, e os internos contêm dados reais de negócio. O que podemos fazer à sua frente, no ecrã, é outra coisa: abrimos o repositório, mostramos-lhe as regras do domínio escritas em texto, corremos as suites de testes — 38 em meio segundo num, 81 em pouco mais de um segundo noutro, 44 no terceiro — e lemos juntos o código que faz a afirmação que você põe em causa. Este site é, por sua vez, um sistema próprio que pode ser inspecionado a partir do exterior.

O nosso sistema antigo não tem API. É possível fazer alguma coisa?

De um modo geral, sim, mas com risco declarado. A ordem é: primeiro perguntamos se o fornecedor tem uma API oficial que simplesmente não documentou publicamente — isso acontece com frequência. Se não tiver, pode trabalhar-se por autenticação programática, exatamente como um utilizador, com sessão renovada automaticamente; construímos assim um sistema que interroga dois portais B2B. Nessa altura, escrevemos claramente que é uma zona cinzenta face às condições de utilização do fornecedor e que, para grande volume, a solução duradoura é pedir a API oficial. A decisão continua a ser sua, mas informada.

Usam inteligência artificial para escrever o código?

Sim, e não escondemos isso. O que conta são as regras sob as quais isso é feito: cada parte do trabalho termina com testes que correm, com verificação de tipos e com uma revisão das diferenças antes do commit, e os limites estão escritos no repositório — sem publicações em produção a partir do interior do trabalho, sem alterações em contas externas, adaptadores para fornecedores apenas com variante de simulação. Código escrito depressa e sem prova custa mais do que código escrito devagar. O que se vende aqui é a velocidade na parte aborrecida, não a ausência de verificação.

O que fazem quando, a meio, se percebe que a ideia inicial estava errada?

Dizemos. Num projeto próprio de engenharia, após a avaliação, chegámos a uma segunda arquitetura completamente diferente para o mesmo problema e escrevemo-la como alternativa documentada, com os gates que têm de ser ultrapassados antes de qualquer comando, em vez de continuar pela primeira só porque já estava iniciada. O custo de uma mudança de direção a meio é menor do que o de um sistema entregue na forma errada, e a diferença é paga pelo beneficiário em ambos os casos.

Quão grande pode ser o trabalho?

Num extremo, um sistema com três aplicações e doze pacotes comuns num único repositório, 486 ficheiros TypeScript, 68 ficheiros de teste e 151 commits, com base de dados relacional, coordenação efémera separada da source of truth e contratos comuns entre aplicações. No outro extremo, um sistema com um único processo e vinte pontos de entrada, que é exatamente o que é necessário. A amplitude não é uma promessa sobre qualquer tamanho — é a observação de que trabalhámos em ambos os extremos.

Fazem também manutenção após a entrega?

Sim, mas como acordo separado, não como subentendido. Um sistema à medida precisa de atualizações de segurança, de acompanhamento das mudanças nos fornecedores externos e de alguém que olhe para os registos. Se preferir fazer isso com a sua equipa, a entrega é construída para o permitir. Se preferir que o façamos nós, escreve-se o que cobre e o que não cobre — incluindo o que significa «urgente», porque sem definição essa palavra não significa nada.

Em que se baseiam as afirmações acima (15 fontes)

15 delas são código e ficheiros dos nossos repositórios. Não publicamos o nome nem a linha: juntos, numa única página, descreveriam com demasiada precisão como estão construídos sistemas que não são só nossos. Percorremo-los consigo, no repositório, a pedido — a verificação continua possível, só que se faz numa conversa.

Como trabalhamos Todos os serviços

O que gostaria que funcionasse melhor?

Conte-nos o seu processo. Em conjunto decidimos o que vale a pena construir, o que podemos ligar e como verificamos o resultado.

Vamos falar