Projetos representativos — anonimizados

Trabalho e Capacidades

Ainda não temos casos de estudo com nome de cliente para publicar, e não vamos inventar uns que soem melhor. O que se segue é o padrão honesto do trabalho que fazemos — quatro projetos representativos, anonimizados e claramente identificados como tal — mais as práticas por trás de todos eles.

Composição estrutural abstrata representativa de um projeto de engenharia real, anonimizado
Composição abstrata em camadas representativa de um projeto de engenharia real, anonimizado
Composição modular abstrata representativa de um projeto de engenharia real, anonimizado
Composição abstrata de estabilização representativa de um projeto de engenharia real, anonimizado
Composição estrutural abstrata representativa de um projeto de engenharia real, anonimizado
Projeto representativo — anonimizado

Plataforma de operações para uma empresa de logística e distribuição

Problema
A empresa geria encomendas, contagens de stock e comunicação com fornecedores em três folhas de cálculo e uma caixa de correio partilhada. Ninguém confiava totalmente nos números, e integrar uma nova pessoa na equipa exigia semanas a aprender por tradição oral.
Abordagem
Passámos as duas primeiras semanas a mapear o processo real de trabalho — não a versão que constava do organograma — antes de escrever uma única linha de código, e depois substituímos as folhas de cálculo por uma única ferramenta interna que refletia como o armazém e o escritório realmente trabalhavam, exceções incluídas.
Stack
Node.js, PostgreSQL, TypeScript, React, AWS
Resultado
As contagens de stock e as encomendas a fornecedores passaram a viver num único sistema que toda a equipa consegue ver e em que confia, e a empresa deixou de precisar de uma pessoa específica na sala para saber o que há em stock.
Desenvolvimento de Software à Medida →
Composição abstrata em camadas representativa de um projeto de engenharia real, anonimizado
Projeto representativo — anonimizado

Portal de gestão de subscrições para uma empresa de media

Problema
Uma empresa de media com modelo de subscrição precisava de um portal de self-service para que os assinantes pudessem gerir a faturação, suspender ou atualizar os seus dados — trabalho que, até então, uma pequena equipa de apoio ao cliente tratava manualmente, email a email.
Abordagem
Construímos o portal como uma aplicação web independente, integrada com o fornecedor de faturação já existente do cliente, priorizando primeiro o punhado de fluxos que geravam mais pedidos de suporte, para que o impacto fosse visível antes de todo o roteiro estar concluído.
Stack
TypeScript, Next.js, Node.js, Stripe, PostgreSQL
Resultado
Os assinantes gerem agora as suas próprias contas sem enviar email ao suporte, e a equipa de apoio passa o tempo nos pedidos que realmente precisam de uma pessoa.
Desenvolvimento de Aplicações Web →
Composição modular abstrata representativa de um projeto de engenharia real, anonimizado
Projeto representativo — anonimizado

Aplicação de campo para uma empresa de facility management

Problema
Os técnicos de campo registavam os trabalhos concluídos em papel e fotografias enviadas por WhatsApp, o que significava que o escritório estava sempre um dia atrasado em relação ao que realmente tinha sido feito.
Abordagem
Definimos o âmbito de uma aplicação móvel multiplataforma à volta das condições reais de trabalho dos técnicos — com funcionamento offline como prioridade, porque o sinal no terreno era pouco fiável — com um painel web leve para o escritório. A estratégia de plataforma e o comportamento offline foram acordados com o cliente antes de se iniciar qualquer trabalho de interface.
Stack
React Native, Firebase, REST APIs
Resultado
O estado dos trabalhos fica visível para o escritório em tempo real assim que o técnico volta a ter cobertura, e as folhas de trabalho em papel deixaram de existir.
Desenvolvimento de Aplicações Móveis →
Composição abstrata de estabilização representativa de um projeto de engenharia real, anonimizado
Projeto representativo — anonimizado

Estabilização e modernização de um sistema legado de gestão de retalho

Problema
Uma empresa de retalho tinha um sistema de clientes e inventário construído por um freelancer entretanto incontactável. Funcionava, mais ou menos, mas ninguém sabia porque é que certas coisas avariavam, e o cliente tinha receio de lhe mexer.
Abordagem
Começámos por uma auditoria completa ao código e às dependências, em vez de uma reconstrução — o cliente precisava de saber o que realmente tinha antes de gastar dinheiro a mudá-lo. A partir daí, estabilizámos as partes de maior risco, acrescentámos cobertura de testes e modernizámos as dependências que representavam um risco de segurança real.
Stack
PHP, MySQL, Docker, CI pipeline
Resultado
O sistema corre agora sobre dependências suportadas, com uma base de código documentada, e o cliente tem um registo escrito do que o sistema faz e não faz, em vez de conhecimento informal disperso pela equipa.
Manutenção, Suporte e Modernização →

Áreas de capacidade

Engenharia

Desenvolvimento backend, frontend e móvel nas linguagens e frameworks que cada projeto realmente exige, não uma stack fixa que forçamos em tudo.

Produto e Design

Investigação de UX, design de interface e prototipagem, feitos por pessoas que também sabem o que é viável construir.

Prática de entrega

Orçamentos escritos, construções faseadas, demonstrações semanais e uma entrega documentada — o processo faz parte do entregável.

Plataforma e DevOps

CI/CD, ambientes de pré-produção, monitorização e infraestrutura cloud, montados para que o sistema continue a funcionar depois de sairmos.

Práticas de engenharia

01
Testes
A lógica central e os fluxos críticos são cobertos por testes automatizados antes de chegarem à pré-produção.
02
Integração contínua
Cada alteração passa por uma pipeline automatizada de build e testes antes de ser integrada.
03
Revisão de código
Nenhum código chega à produção sem ser revisto primeiro por um segundo engenheiro sénior.
04
Documentação
As decisões de arquitetura e a configuração dos ambientes ficam escritas à medida que avançamos, não reconstruídas no final.
05
Entrega
Cada projeto termina com uma entrega documentada: acessos, notas de arquitetura e um guia de manutenção.
06
Segurança
As dependências são mantidas atualizadas, e o acesso segue o princípio do menor privilégio por definição.

Tecnologias que usamos de facto

Fale-nos sobre um projeto semelhante.

Se alguma destas situações se parece com a sua, conte-nos a sua — vamos ser diretos sobre se é ou não um bom encaixe.

Escolha o que lhe é mais confortável. Pode alterar esta escolha a qualquer momento a partir do link 'Preferências de cookies' no rodapé.

Essencial

Necessário para o site funcionar — guarda apenas a sua escolha de cookies (cbl_consent). Não pode ser desligado, e não o rastreia.

Análise de dados

Google Analytics 4 (GA4) — ajuda-nos a perceber como o site é utilizado, de forma agregada. Só é ativado se ligar esta opção.