Produtos que você pode entender. Sistemas sobre os quais podemos construir.

O que havia para resolver

Um centro médico com um nomenclátor de centenas de serviços tarifados precisava de que cada serviço fosse uma página própria, encontrável na pesquisa, com preço e unidade de medida — não um PDF com a lista de preços. Além disso, os preços e a equipa mudam, por isso a clínica tinha de poder editá-los por conta própria, e as marcações tinham de chegar imediatamente à receção, não a uma caixa de e-mail.

Qué construimos

Next.js 14.2.35 (App Router) com React 18, TypeScript e Tailwind. Cada item do nomenclátor médico tornou-se uma rota estática própria: 521 ficheiros `page.tsx` em `src/app`, dos quais 481 sob `/servicii` — 184 fisioterapia, 122 serviços consultivos, 61 exames médicos periódicos, 27 ginecologia, 26 ozonoterapia, 23 pacotes de tratamento, 18 medicina alternativa, 12 diagnóstico, o restante por secções. O sitemap em produção lista 890 endereços. O site é bilingue ro/ru. O conteúdo editável (médicos, pacotes, tratamentos, artigos, definições, imagens) está numa base SQLite local através de `better-sqlite3`, com diário WAL e chaves estrangeiras ativas, administrada a partir de `/admin` através de 20 rotas API; a autenticação usa `jose` para sessão e `bcryptjs` para palavra-passe, e a alteração da palavra-passe invalida as sessões existentes. Os formulários de marcação e de contacto são validados com `zod` + `react-hook-form` e enviam a mensagem formatada diretamente para o Telegram, através da Bot API. Existe também uma calculadora de preço em `calculator`.

O que havia para resolver

O menu de um clube muda com frequência, tem preços e volumes que têm de ser exatos, e é lido no telemóvel, no escuro, por pessoas que falam três línguas. Um PDF digitalizado num código QR não resolve nada disto: não se pode pesquisar, não se traduz, não se atualiza sem voltar a imprimir o código.

Qué construimos

Um menu digital sem estrutura de trabalho e sem pacotes: as fontes reais são quatro ficheiros JSON, e um gerador Python de 402 linhas escreve a partir deles um único `index.html`. 119 produtos em 21 categorias, cada um com preço, volume, composição e fotografia; 119 textos curtos de apresentação, um por produto; 119 conjuntos de recomendações de combinação („com o que combina”), que o visitante vê em cada cartão. O menu tem três línguas: o romeno é a base, e o russo e o inglês cobrem não só a interface, mas também as categorias, os volumes, as composições, as 82 etiquetas de sabor e todos os 119 textos de apresentação. O carrinho, a lista de favoritos e a divisão da conta funcionam no navegador, sem conta e sem servidor. As fontes estão alojadas no mesmo domínio, não no Google. Antes de cada publicação, um script de 233 linhas executa 16 verificações — que não se infiltrou nenhum rastreador, que não se pede nada a um domínio de terceiros, que o JSON é válido e cada imagem existe, que o menu está completo em todas as três línguas, que os preços descem em cada categoria e que os dados estruturados da página são válidos. A publicação é feita automaticamente pelo GitHub Actions na fusão para `main`, depois de o workflow fazer uma cópia completa da produção e a guardar durante 30 dias.

O que havia para resolver

Uma câmara municipal de comuna deve ter uma página web oficial em conformidade com a HG 728/2023 — com secções fixas (transparência decisória, projetos e decisões, anúncios, documentos, contactos, orçamento) — e deve poder atualizá-la sozinha, sem programador a cada anúncio. Sem isso, a informação de interesse público fica em papel ou num grupo de Facebook.

Qué construimos

Aplicação Laravel 12 em PHP 8.2 com MySQL 8, front-end Vite + Tailwind, empacotada em dois contentores Docker (`japca_app` = nginx + PHP-FPM, `japca_db` = MySQL). A arquitetura separa intencionalmente dois tipos de conteúdo: o editorial, que muda raramente (geografia, história, instituições, contactos, orçamento), fica num único ficheiro de configuração PHP de 1613 linhas que os templates Blade leem diretamente, e o que muda com frequência (anúncios, galeria de fotos, projetos e decisões, documentos, definições de transparência) fica no MySQL e é editado a partir do painel `/admin`. 40 templates Blade, 32 rotas, 10 migrações de base de dados. A autenticação no painel é limitada a 5 pedidos por minuto a partir do mesmo endereço — o sexto recebe 429 — e cada ação de administração entra numa tabela de auditoria. Os cabeçalhos de segurança e o sitemap são cobertos por testes automáticos que correm no CI.

O que havia para resolver

O mesmo que em qualquer menu por código QR: tem de ser rápido no telemóvel, correto no preço, legível em três línguas e alterável em cinco minutos quando a cozinha retira um prato. Além disso, o restaurante não precisa de qualquer rastreio de clientes — e então a pergunta real é se alguém realmente constrói um site que não recolhe nada, ou se apenas escreve isso na política de privacidade.

Qué construimos

Um único `index.html` gerado por um script Python de 377 linhas a partir de ficheiros JSON: 146 produtos em 31 categorias, 143 textos curtos de apresentação, mais as traduções para russo e inglês de categorias, nomes, volumes, composições, etiquetas e textos. O carrinho, a lista de favoritos e a divisão da conta correm no navegador. O site é servido diretamente por Caddy 2, com HTTPS automático. O interessante é que a não deteção do utilizador não é uma promessa, mas uma regra imposta pela integração contínua: em cada pedido de fusão, o CI regenera `index.html` a partir das fontes e rejeita o PR se o resultado diferir do ficheiro no repositório (logo, a página publicada corresponde sempre às fontes), depois executa 14 verificações — sem trackers, sem qualquer recurso carregado automaticamente a partir de um domínio de terceiros, fontes alojadas localmente, sem ficheiros de backup a chegarem ao repositório, política de privacidade presente e ligada a partir do rodapé, menu completo em três idiomas, preços por ordem decrescente em cada categoria, dados estruturados válidos — e verifica também que da configuração do servidor não desapareceram os cabeçalhos de segurança nem a ocultação do endereço IP nos registos. Todas as ações GitHub usadas estão fixadas ao hash do commit, e o workflow começa com `permissions: {}`.

O que havia para resolver

não verificado — não temos as fontes, por isso não posso descrever o problema de trabalho sem o inventar.

Qué construimos

Aplicação React compilada com Vite, servida estaticamente por nginx, com versão em russo em `/ru/`. 181 endereços no sitemap de produção. Só isto pode ser afirmado do exterior: as fontes não estão nesta máquina, por isso não posso nomear as bibliotecas, a estrutura ou as integrações.

O que havia para resolver

Um centro estomatológico distrital precisava de uma lista pública de serviços com preços, marcação clara dos que são cobertos pelo seguro obrigatório, equipa, horário de urgências e páginas de transparência — editáveis pelo pessoal, não pelo programador. Quando assumi o projeto, o painel de administração tinha um problema grave: a palavra-passe de admin era comparada no navegador e acabava no pacote JavaScript público, e os pedidos de escrita na API podiam ser feitos por qualquer pessoa na internet.

Qué construimos

Aplicação React 18 + TypeScript em Vite 6, com roteamento `react-router-dom` — 22 ecrãs, de serviços e preços até urgências, ortodontia, implantes, pedodontia, transparência e feedback. Nos bastidores, uma API Express 4 iniciada sob PM2; o nginx serve os ficheiros construídos e encaminha apenas `/api`. Os dados públicos (serviços, equipa) estão em ficheiros JSON lidos tanto pela API como diretamente pelo front-end. A parte que nós trouxemos foi a segurança: a palavra-passe já não sai do servidor — `POST `login` verifica-a aí e devolve um token assinado HMAC-SHA256 válido por 12 horas, com limite de 8 tentativas por 15 minutos por endereço IP e comparações em tempo constante; as escritas em `services` e `team` agora exigem o token; o segredo de assinatura é gerado automaticamente num ficheiro com permissões 0600, mantido fora do repositório; a API escuta apenas em 127.0.0.1, por isso o nginx é o único caminho público; o CORS é limitado aos domínios próprios, e o corpo JSON é limitado a 1 MB. Além disso, acrescentámos CI que compila, verifica tipos e rejeita o pacote se encontrar um segredo nele, mais Dependabot com ritmo semanal para npm.

O que havia para resolver

Uma empresa de crédito precisa de mais do que um site: o pedido deve entrar online, passar por um fluxo de decisão, produzir um contrato PDF, gerar um plano de pagamentos e deixar rasto na auditoria — e tudo deve resistir às perguntas feitas por um cliente que pede de volta os seus dados pessoais. A parte pública (calculadoras, artigos, páginas por tipo de crédito) deve, ao mesmo tempo, trazer pessoas a partir da pesquisa.

Qué construimos

Duas metades no mesmo depósito. A parte pública é uma aplicação Vite + React Router compilada estaticamente — 50 ecrãs, entre os quais quatro calculadoras (crédito, elegibilidade, refinanciamento, plano de pagamentos), páginas separadas por tipo de crédito, blog, páginas de informação pré-contratual e de conformidade. As rotas romenas ficam sem prefixo, e as russas vão em `/ru/…`, com etiquetas canónicas e alternativas geradas a partir da língua da rota ativa. A parte de negócio é um backend Express modular em TypeScript, com Prisma sobre PostgreSQL: 16 módulos — autenticação, direitos por função, fluxo dos pedidos, documentos, pagamentos, notificações, tarefas agendadas, blog, SEO, GDPR, clientes, leads, contacto, calculadora, Google Ads, saúde — e 18 tabelas no esquema Prisma, entre as quais `Contract`, `Payment`, `AuditLog`, `GdprRequest`, `UploadedDocument`, `DailyKpiSnapshot` e `CronJobRun`. Funciona sob PM2, com scripts separados para migrações em produção, verificações antes do lançamento, geração de segredos, cópia de segurança e restauração da base de dados.

O que havia para resolver

Um serviço automóvel é procurado em combinações muito específicas — marca mais operação mais bairro („reparação da caixa automática BMW Botanica”). Uma única página „Serviços” não consegue responder a nada disso. O problema técnico é que o site é uma aplicação React de uma só página, por isso o que o motor de pesquisa vê é um `<div>` vazio se não se fizer algo específico.

Qué construimos

Aplicação React 19 + TypeScript em Vite 6, com React Router, mas pré-renderizada na compilação: cada rota sai do build como um ficheiro HTML próprio, por isso o motor de pesquisa recebe conteúdo, não uma página vazia. A estrutura de endereços foi alargada em etapas verificáveis no histórico — de 206 páginas indexáveis, para 316 com a adição das combinações marca × categoria de trabalho, dos artigos e das páginas por setor de Chișinău. As rotas têm versões por língua, um sitemap de imagens separado, imagens Open Graph e o pacote JavaScript dividido para carregamento mais rápido. O último commit corrigiu um detalhe que estraga a indexação em silêncio: o endereço canónico, o `hreflang` e os endereços no sitemap emitem agora todos a mesma forma com barra final.