Vinte e oito sistemas, descritos com sinceridade.

Django 5.2, PostgreSQL e MariaDB, renderização no servidor, sem SPA. Cerca de 120 modelos em catorze apps e 170 templates. Instalado em alojamento partilhado sob Passenger, com cron em vez de Celery porque nenhum processo em segundo plano sobrevive ali.

Conversions API do lado do servidor com desduplicação face ao Pixel do browser através de um event id partilhado, dados pessoais em hash, disparada numa thread em segundo plano e a fazer fail open. Drivers de impressora fiscal com um modo degradado de driver nulo, para que um equipamento inacessível marque o talão como pendente em vez de bloquear a venda. Uma API com bearer token para um cliente Windows de registo de horas fora do repositório, que envia capturas de atividade minuto a minuto. Um sistema de papéis resolvido por prioridade - superutilizador, depois grupo, depois registo de funcionário da clínica - a alimentar dez dashboards diferentes a partir de uma só base de código.

Django 5.2, PostgreSQL, Stripe, construtor de páginas GrapesJS no admin. Vinte e cinco modelos em quatro apps com modelos.

O backend de IA fica atrás de um único tipo de resultado normalizado com três implementações intermutáveis - mock, API alojada e auto-alojada - escolhidas por uma variável de ambiente, pelo que o produto inteiro funciona de ponta a ponta sem nenhum fornecedor de IA ligado e sem alterar código. Um pipeline clínico de carregamento → análise → achados → plano de tratamento → linhas de orçamento, com cada achado a carregar a sua própria banda de confiança. Middleware de atribuição de primeiro contacto que capta os click ids de quatro plataformas de anúncios para um relatório de funil de lead a cliente pagante.

Django 5.2, MySQL, modeltranslation em três apps, CKEditor 5, construtor de landing pages GrapesJS.

Uma máquina de estados do pedido de marcação até à aprovação: o pedido de um visitante fica pendente até a equipa aprovar, momento em que se cria ou associa uma ficha de paciente e se materializa uma marcação real. Cada lead guarda as suas respostas duas vezes - em JSON e em linhas individuais - a par de IP, user agent, referrer, geografia e o conjunto completo de UTM e click ids da Meta. As landing pages de campanha são montadas fora do routing com prefixo de idioma, para que o tráfego pago nunca caia num redirecionamento de locale.

Django 5.2 com DRF e JWT, PostgreSQL, Celery e Redis, hashing com Argon2, quarenta e nove apps locais. React com Vite e Tailwind no front, Flutter no mobile. Sentry, gunicorn com gevent.

Um motor de recomendação que classifica sete estados do sistema nervoso a partir de um check-in, aplica portas rígidas de elegibilidade, comprime a prioridade numa banda de seis pontos para que o contexto vença a popularidade, e depois amostra por softmax em vez de tomar o argmax - de modo que o catálogo inteiro se mantém alcançável, em vez de colapsar sempre nos mesmos vinte itens. Um quarto lugar fica reservado à descoberta e é amostrado por recência. Corre sobre queries diretas do driver e não sobre o ORM, porque é executado em todos os ecrãs. O retrieval assenta em cerca de trinta mil soluções estruturadas extraídas de perto de noventa e cinco livros, com um prompt que proíbe o modelo de responder a partir do seu próprio conhecimento geral e um ramo explícito para situações de crise. Um harness de Monte Carlo corre o motor real sobre sessões sintéticas - cinquenta mil check-ins numa execução, setenta mil sessões equilibradas noutra - a garantir que nenhum estado de crise recebe um cartão inadequado e que nenhum cartão é inalcançável. Também revelou uma falha real de deteção, que é precisamente para isso que serve um harness. A escolha de fornecedor e todas as chaves de API são resolvidas a partir de uma tabela editável no admin antes de recorrer ao ambiente, pelo que fornecedores e chaves rodam sem um deploy.

Django 5.1, MySQL em produção com PostgreSQL e SQLite como alternativas em desenvolvimento, Celery e Redis com fallback eager, bloqueio com django-axes, profiling com Silk, construtor GrapesJS. Quarenta modelos em seis apps.

A finalização do pagamento é deliberadamente duplicada e idempotente - a mesma rotina corre a partir do webhook da Stripe e da página de retorno, que sai de imediato se a reserva já estiver paga, para que um webhook perdido não possa perder uma reserva paga. O channel manager não oferece qualquer esquema de assinatura de webhooks, por isso o endpoint é autenticado por um segredo no caminho do URL, com um teste que o deixa vazio para provar que faz fail closed. Uma máquina de estados de reserva encaminha as estadias confirmadas para o canal direto e os bloqueios para outro canal; a propriedade sem id de canal é associada localmente por slug. Todos os emails de saída são persistidos antes do envio por um backend de correio personalizado.

Django 5.1, MySQL, Celery com fallback eager e Redis opcional, admin Unfold com um studio incorporado no repositório, HTMX e Alpine sobre Tailwind. Cerca de quarenta modelos em dez apps. Flutter nos dois clientes móveis, JWT em armazenamento seguro.

Um checkout a decorrer é mantido como reserva temporária e só é promovido a reserva real quando a Stripe confirma a sessão, de modo que os checkouts abandonados nunca ocupam inventário. Seis tipos distintos de documento fiscal partilham mixins comuns de partes e de linhas, em vez de serem um único modelo de fatura com uma flag de tipo. As fichas de hóspede reconciliam-se entre canais através de uma camada de hóspede canónico, com registos separados para pessoas singulares e empresas, para que a mesma pessoa vinda de uma OTA e de uma reserva direta seja um só registo. Todos os segredos de integração são resolvidos primeiro a partir da base de dados, com uma cache de sessenta segundos, pelo que as chaves rodam em produção.

Django 5.0, MySQL, modeltranslation em oito idiomas, Tailwind e Alpine a partir de CDN sem passo de build. Trinta e oito modelos.

Confirmação da reserva por código de seis dígitos enviado por email, com limite de tentativas por IP fixado em cinco, validade de quinze minutos e um período de espera para reenvio. Tokens assinados e com prazo dão a um visitante anónimo acesso à sua própria página de reserva durante vinte e quatro horas, sem conta. O preço é recalculado no servidor em cada gravação, a partir de uma tabela de cinco escalões de dias cruzada com o nível de seguro, com o desconto aplicado apenas ao subtotal do aluguer - nunca aceite a partir do cliente.

Django 5.1, MySQL, Redis e Celery, DRF com JWT e OpenAPI, admin Unfold, modeltranslation e parler. Uma aplicação React 19 construída com Vite e entregue já compilada. Catorze apps, sete idiomas com catálogos de tradução completos.

Scoring de leads por modelo de linguagem com pesquisa web: as respostas do formulário, os UTMs, os click ids, o resultado da autenticação e o estado face à lista de não-contactar são reunidos num dossiê e classificados numa banda, com fundamentação e uma ação recomendada, usando uma chave por cliente. Uma camada de conformidade em três partes - limpeza completa com deteção do tipo de linha e de número móvel, verificação de litigantes e consulta de números reatribuídos face à data do consentimento. O tenant é resolvido a partir do cabeçalho Host com uma cache de cinco minutos, e cada submissão de formulário é reverificada contra o cliente desse host, pelo que um lead entre tenants é estruturalmente impossível. O construtor de formulários guarda um HMAC de cada código de verificação em vez do código, e cada checkbox de consentimento escreve um registo imutável da redação exata, do IP e do URL.

Django 5.2 com Wagtail, dois repositórios de dados - PostgreSQL para o estado operacional e ClickHouse para a torrente de eventos de tracking - Redis, Celery com beat e Flower, DRF mais uma camada JWT feita à mão para o mobile. Quarenta e seis modelos só na app principal.

Cada fornecedor mapeia para uma de três subpontuações - contactabilidade, autenticidade, intenção - executadas em paralelo através de um pool de threads e reduzidas por média a uma nota composta, com pesos ajustáveis no admin. Os adaptadores que dão erro ou são saltados saem do denominador em vez de pontuarem zero, e qualquer adaptador bloqueante impõe de imediato a nota mais baixa. O conjunto de sinais inclui biometria comportamental, fingerprinting de TLS, profundidade de scroll e cadência de preenchimento do formulário, a par de três subsinais de modelo de linguagem. O encaminhamento para compradores filtra por crédito, horário de funcionamento, capacidade diária e semanal, vertical e geografia, e depois desempata pela carga das últimas vinte e quatro horas antes da prioridade. Cada chamada a um fornecedor escreve uma linha de log com endpoint, estado e resumo da resposta, precisamente para que o custo de fornecedores por lead possa ser reconciliado.

Flutter com Riverpod, Dio e go-router, armazenamento seguro para os tokens. Uma app Django complementar que expõe o registo do admin como REST.

As permissões não são reimplementadas: a API mapeia os verbos HTTP para as próprias permissões de ver, adicionar, alterar e eliminar do Django, e a pesquisa, a paginação e a ordenação das listas vêm diretamente da configuração de cada classe do admin. Acrescentar um modelo ao admin do Django acrescenta-o à aplicação móvel. Uma aplicação irmã para compradores replica os catorze conjuntos de tema por cliente da aplicação web, lendo o que está ativo no início de sessão e guardando-o em cache para que a marca errada nunca apareça por instantes no arranque a frio.

Django 5.2 com Wagtail, MySQL, Redis, Celery com beat, Channels e Daphne para WebSockets, DRF com JWT, pandas e numpy, web3 para o canal de pagamento em cripto. Flutter e Dart nos clientes móvel e de desktop, um único lib/ partilhado pelos três. Dezassete idiomas configurados.

Sete leituras independentes de indicadores por timeframe, e um timeframe só concorda quando pelo menos cinco das sete coincidem - depois confirmação multi-timeframe por cima, com portas opcionais de candlestick e de notícias e stops e alvos derivados do ATR. Cada passagem escreve uma linha de auditoria, tenha ou não produzido um sinal, e o dry-run é o comportamento por omissão. O canal de pagamento em cripto não guarda nenhuma chave privada no servidor: uma tarefa agendada vigia a cadeia à procura de transferências para um endereço de receção, associa os depósitos pendentes pelo valor e confirma ao fim de doze confirmações. Duas middlewares empilhadas tornam o produto inacessível enquanto o onboarding não estiver genuinamente completo.

Django 4.2, MySQL, admin Unfold com um dashboard em Chart.js, modeltranslation em oito idiomas, Tailwind e Alpine a partir de CDN. Sessenta e dois modelos em nove apps, sessenta e três tabelas.

A cadeia de fulfilment é real e não declarativa: a geração da guia de transporte regista o pedido, a resposta e o erro completos na encomenda, e a faturação emite documentos e estornos sobre ela. O preço em duas moedas guarda o valor nativo e o valor apresentado como um par, em vez de um valor e uma taxa, para que uma encomenda antiga não seja silenciosamente reavaliada quando o câmbio se move.

Django 4.2, MySQL, admin Unfold, ReportLab com um tipo de letra próprio registado para a composição dos PDFs. Cinquenta e cinco modelos.

O corpo do contrato é um modelo legal estruturado que se numera sozinho, fixa os dados do beneficiário no momento da assinatura e valida que um contrato liga a uma pessoa singular ou a uma empresa, mas nunca às duas. Os PDFs de proposta são compostos divisão a divisão - oito tipos de divisão, cada um com a sua descrição, preço e fotografias - como um documento paginado e não como o preenchimento de um template. Todos os valores monetários são guardados nas duas moedas, em colunas paralelas.

Django 5.2, MySQL, admin Unfold com templates próprios de calendário e de folha de horas. O cliente de desktop é Tkinter - cerca de 1.600 linhas - empacotado com PyInstaller num único executável e distribuído por um instalador.

A lógica de saída automática é a parte interessante: uma sessão fecha no seu último heartbeat apenas quando já passou o fim do dia previsto e não chega nenhum heartbeat há dez minutos - e um heartbeat posterior, com um carimbo temporal de aplicação viva, pode ressuscitar uma sessão que uma falha real tenha fechado. É um problema de estado distribuído tratado como deve ser, e não um cron noturno que adivinha.

Laravel 11 com Breeze, MySQL, Blade com Vite, Tailwind e Alpine, DomPDF. Onze modelos, dezoito migrações.

Nada de invulgar em termos de arquitetura, e não deve fingir o contrário: é uma ferramenta interna pequena e correta. A parte substancial é o dashboard do pipeline, que agrega contagens por tipo de espaço e por utilização, a distribuição por escalão de área e o orçamento médio face ao valor total e ao valor pago das proformas.

Django 4.2, MySQL, admin Unfold, modeltranslation em dez idiomas, Tailwind e Alpine. Cerca de trinta modelos. Um plugin complementar para a ferramenta de design, fora do runtime do Django.

O pipeline recebe código colado, gera a partir dele diagramas de arquitetura e de fluxo, e depois constrói uma especificação de ecrãs e de paleta que um plugin da ferramenta de design vai buscar e desenha como frames reais e editáveis. É uma ferramenta pequena, mas tira a hora menos agradável do início de qualquer projeto.

Apenas a biblioteca padrão do Python. Sem framework, sem dependências, sem passo de build, cerca de 920 linhas. O servidor é o próprio servidor HTTP da biblioteca padrão, com uma fila de tarefas em threads.

Trata corretamente a autenticação em dois níveis do fornecedor - credenciais de serviço para emitir credenciais de cliente, depois credenciais de cliente para a geração, guardadas em cache e reutilizadas - e trata a geração como genuinamente assíncrona, sondando cada tarefa na sua própria thread com um timeout. Sem credenciais configuradas, a UI desativa a geração e di-lo, em vez de falhar no momento de uso.

PHP e Laravel 8 com Jetstream e Livewire, MySQL, templates Blade, Laravel Mix a compilar Tailwind, Bootstrap, jQuery, Alpine e Sass. Treze modelos, vinte e nove migrações, trinta e dois controladores, Apache em cPanel.

A tradução vive no schema e não num pacote: os modelos de post, loja, galeria e menu levam cada um quatro conjuntos de colunas paralelos, um por idioma, e o romeno chegou cinco anos depois do lançamento através de migrações que alargam todos eles. É um desenho mais tosco do que uma tabela de traduções e tem uma virtude real - ler uma linha traduzida é a mesma query que ler uma não traduzida, sem join e sem lógica de fallback para correr mal. Vale a pena dizê-lo com clareza: isto é um monólito CRUD convencional sobre uma stack que envelheceu. O que demonstra não é engenho, mas sim que foi mantido discretamente durante anos depois da entrega.

Django 4.2, MariaDB, admin Jazzmin com inlines aninhados, modeltranslation e Rosetta para editar traduções no browser, Bootstrap e AOS. Trinta modelos. Quatro contentores: nginx, web, base de dados e um agendador.

O emissor de campanhas calcula quantos intervalos passaram desde a hora de início e envia o lote seguinte de dez destinatários, acompanhando o progresso e escrevendo um registo de entrega com um message id gerado por destinatário - uma limitação de cadência pensada para sobreviver a um servidor de correio partilhado, em vez de pressupor um fornecedor de entrega. Depois, uma tarefa de hora a hora consulta o IMAP, interpreta as notificações de devolução e reconcilia-as com esses registos de entrega pelo message id. Por baixo, defesas em camadas contra abuso: armadilhas de URL do tipo honeypot que banem o IP de origem durante trinta dias, uma blocklist de bots maliciosos e limites de taxa por view.

HTML estático com Tailwind compilado numa única folha de estilos, módulos de JavaScript puro, um único endpoint em PHP para o formulário de contacto. Apache em alojamento partilhado.

O endpoint de correio fala SMTP diretamente - abre um socket TLS e faz ele próprio o handshake de autenticação, sem nenhuma biblioteca de email - porque o alojamento não oferecia alternativa utilizável. A analítica é genuinamente consent-first: a tag não é sequer carregada enquanto o consentimento não estiver guardado, respeita ainda o Do-Not-Track e recusa-se a correr fora do hostname de produção. A escrita da direita para a esquerda é tratada no código-fonte do Tailwind, em vez de acrescentada como uma segunda folha de estilos, e cada URL declara as suas alternativas de idioma.

Django 4.2, MySQL, admin Unfold, modeltranslation. PayPal chamado diretamente por REST em vez de através de um SDK.

Um padrão de CMS com modelos singleton em que cada uma das cerca de vinte secções de página cria automaticamente a sua linha na migração, para que quem edita nunca abra o admin num ecrã vazio e nunca tenha de saber o que é uma fixture. Todas as chaves de terceiros vivem num cofre em base de dados e não em ficheiros de ambiente, o que é a troca certa para um cliente que muda de fornecedor mais vezes do que faz deploy.

HTML estático. Sem framework, sem base de dados, sem passo de build - a resposta certa para um catálogo que muda duas vezes por ano e tem de sobreviver à janela de suporte de qualquer framework.

Nada, e é esse o ponto. Nem todos os briefings são um sistema, e um site estático que o cliente pode alojar em qualquer lado durante uma década é aqui um resultado melhor do que um CMS em que ninguém vai entrar.

Django 4.2 com django-unfold, MySQL através de PyMySQL, modeltranslation em oito idiomas, CKEditor para os campos de texto longo, Tailwind e Alpine carregados de um CDN sem passo de build, Whitenoise, Passenger em cPanel. Trinta e dois modelos em três apps.

Nada aqui é difícil, e a entrada ganha o seu lugar por demonstrar a competência oposta: um site cujo dono nunca precisa de um programador para mudar uma palavra. A falha honesta está à vista no schema - o modelo de portefólio ainda carrega um campo de área e um campo de localização herdados do template imobiliário de que foi forkado, e cerca de um terço da lista de dependências vem arrastada e nunca é importada. É isto que custa, na prática, forkar um projeto que funciona para poupar uma semana, e prefiro mostrá-lo a limpá-lo da história.

Vue 3 com a Composition API, Vue Router, Vite com chunking manual de vendors, Tailwind, GSAP, ícones Lucide. Cerca de seis mil e trezentas linhas em oito rotas, uma das quais é uma página de design system. Apache a servir o resultado da build.

Doze componentes de animação, um por serviço, escritos e não trazidos de uma biblioteca, com composables de intersection observer e de contagem crescente por baixo. É trabalho de ofício e é essa toda a sua ambição. Traz também o exemplo mais claro que tenho de uma dependência que sobreviveu ao seu propósito: o reCAPTCHA v3 carrega em todas as páginas e não protege nada, porque não há formulário nenhum no site - a rota de contacto é um link mailto, e a biblioteca de validação instalada para o formulário que nunca chegou a ser feito continua no manifesto. Um script de terceiros que corre em cada carregamento de página e não faz nada é uma responsabilidade em matéria de consentimento, e não um resto inofensivo, e está na lista para remover.

Solidity 0.8.24 com OpenZeppelin 5.1 fixado na versão exata, Hardhat e ethers v6, Node 20 para o relayer e o faucet, Terraform e Docker Compose para a frota de validadores, uma stack Blockscout incorporada no repositório atrás de nginx para o explorador, JavaScript puro para as dApps e para a carteira, Rust e Anchor para o lado da Solana. 3.500 linhas de Solidity original, 12.000 de JavaScript, 142 testes de contrato em quatro suites.

Um único ficheiro de alocação é a fonte de verdade para a oferta total de cem milhões, e a build gera a partir dele o genesis, os diretórios de compose por papel e os scripts de deploy, tanto para devnet como para testnet e mainnet - de modo que as três redes não se podem afastar umas das outras. Um passo de preflight recusa-se a construir um genesis de mainnet enquanto restar algum endereço de placeholder. O faucet reimplementa o protocolo WebSocket do próprio cliente de nó, para que a página não precise de um caso especial para redes locais. O relayer só avança o seu cursor de blocos depois de cada mensagem de um intervalo estar persistida, porque avançar primeiro perde transferências para sempre e nada volta a varrer. A conservação da oferta é um invariante de desenho e não uma verificação: exatamente uma cadeia faz escrow e todas as outras cunham, o teto do token é igual à oferta do genesis, e os scripts de deploy não cunham nada. A versão do OpenZeppelin está fixada porque a 5.2 emite um opcode mais recente do que a EVM do nó - uma biblioteca mais recente produziria bytecode que os seus próprios validadores não conseguiriam executar. A bridge é uma bridge de quórum de confiança e é descrita como tal em três sítios distintos, em vez de ser chamada trustless.

Python 3.11 com pandas e numpy, com versões deliberadamente limitadas para que os wheels pré-compilados instalem em alojamento partilhado sem compilador. SQLite para o diário de operações, MySQL para exportação, o próprio servidor HTTP da biblioteca padrão para o dashboard. 18.000 linhas em 94 módulos e 541 testes.

O modelo de linguagem corre no seu próprio relógio, em segundo plano, e escreve uma cache que o ciclo de trading lê instantaneamente, porque uma ida e volta de um a três segundos em barras de cinco segundos significa agir sobre um preço que já não existe - e essa falha é silenciosa, porque a resposta continua a parecer sensata. Pode emitir um viés e dois multiplicadores; não pode inventar uma operação, escolher uma direção, dimensionar uma posição ou mexer num stop, e faz fail open para neutro. A camada de aprendizagem é regressão logística escrita à mão, precisamente para não poder esconder overfitting: dentro e fora da amostra sempre reportados juntos, divisões ordenadas no tempo e uma baseline ingénua de aceitar todas as operações impressa ao lado. As saídas disparam sobre o preço do subjacente e não sobre o prémio da opção, porque o prémio move-se com a volatilidade e com o decaimento temporal. O supervisor usa um lock de ficheiro depois de duas execuções separadas por segundos terem escapado a uma verificação de pidfile e terem deixado dois bots a operar sobre a mesma conta.

Django 4.2, django-unfold, MySQL, modeltranslation em dez idiomas, CKEditor, Tailwind e Alpine a partir de um CDN, Passenger em cPanel. Trinta modelos em três apps, mais um plugin de Figma complementar.

O gerador de Figma constrói a sua árvore de nós de forma determinística - frames, retângulos e texto dispostos por código - e só depois oferece uma passagem opcional por um modelo para a embelezar. Essa ordem é todo o desenho: o mesmo projeto produz sempre o mesmo layout, e o modelo pode melhorar o resultado mas nunca é a razão da sua existência. O plugin vai buscar a sua especificação através de um URL de admin assinado, para que a aplicação de desktop do Figma possa obter um design sem manter uma sessão. Duas lacunas que não vou fingir estarem terminadas: o lado de envio da integração com o Figma ainda é um stub, e o cliente da OpenAI é importado sem estar fixado numa versão, pelo que uma instalação limpa desse painel falha até isso ser acrescentado.

Python 3.11 e Django 5.2 LTS, django-unfold, MySQL através de PyMySQL, Redis, Celery com beat, resultados e Flower, Strawberry GraphQL com a extensão de otimização para Django, modeltranslation, Silk apenas em desenvolvimento, React 18 e Vite para a ilha de front-end. Dez apps, trinta e três modelos, cerca de oito mil e duzentas linhas de Python.

O tracking de conversões dispara duas vezes de propósito: o pixel do browser e a API do lado do servidor enviam o mesmo evento com o mesmo event id, para que a plataforma os desduplique, e os eventos que os bloqueadores removeriam - normalmente entre um quinto e dois quintos deles - sobrevivem. Os campos pessoais são passados por hash antes de saírem, e uma falha de tracking é engolida em vez de propagada, porque vale mais um lead do que um lead perfeitamente reportado. O motor de formulários são nove modelos e doze tipos de pergunta sobre um funil de cinco estados com um registo de auditoria de eventos; os seus endpoints públicos estão deliberadamente isentos de CSRF, porque o markup é escrito no admin e servido tal e qual, e um id de sessão impossível de adivinhar, emitido pelo servidor, faz o trabalho que o token teria feito. Cada restrição de versão no ficheiro de requisitos traz a razão por que existe, incluindo as que eu preferia não ter de ter. O ponto fraco é a cobertura: vinte e três smoke tests contra oito mil linhas, o que não chega e eu sei disso.