AdeiltonPessini

Gestão para barbearias e salões

SaaS multi-tenant

Problema

O setor se organiza em caderno, WhatsApp e três aplicativos que não conversam entre si. As ferramentas do mercado resolvem agenda, ou caixa, ou fidelidade, e nenhuma aproveita o histórico para ajudar o dono a decidir.

Solução

SaaS multi-tenant que cobre o dia inteiro da operação: agenda por profissional e por unidade, fila, lista de espera e encaixe, comanda e PDV, financeiro com comissão, meta e emissão fiscal, estoque com lote e validade, compras e fornecedor. Do lado comercial, loja online com checkout, clube de assinatura, pacote, vale-presente, cupom, fidelidade, indicação e avaliação com NPS. O cliente final tem página pública da unidade, reserva online, área logada com histórico e recibo, e link de avaliação depois do atendimento. Acima disso, uma camada de IA que responde no WhatsApp, antecipa falta e devolve indicador de gestão, e que mede o impacto do próprio bot em vez de pedir fé. Tem também hardware: totem de autoatendimento na recepção e um painel físico com firmware próprio.

Resultado

Isolamento por tenant aplicado no próprio banco, permissão calculada pelo cruzamento de cargo e plano, trilha de auditoria e deploy contínuo. São 176 telas e 199 endpoints sustentados por 557 arquivos de teste automatizado, de unidade a ponta a ponta, que rodam como portão antes do merge. A mesma base sustenta mais de uma marca sem duplicar código.

• Next.js App Router
• TypeScript
• Prisma
• PostgreSQL + RLS
• NextAuth + passkey
• Claude SDK
• Stripe
• Mercado Pago
• Docker Swarm
• Cloudflare

Agendamento para prestadores de serviço

Marca irmã do mesmo núcleo

Problema

O mesmo motor de agendamento atendia outro público, com outro vocabulário e outro posicionamento. Separar em dois produtos duplicaria o código, e neutralizar a linguagem enfraqueceria as duas marcas.

Solução

Arquitetura de marca parametrizada: um código, dois produtos, cada um com identidade, domínio, tema e oferta próprios. A regra de negócio fica compartilhada, o vocabulário do nicho vive na configuração da marca, e o que muda de verdade entre as duas é a linguagem e quais ofertas ficam ligadas. O Agenday acrescenta o modo profissional autônomo e o módulo clínico, com ficha de anamnese, consentimento e evolução do atendimento.

Resultado

Segunda marca no ar sem fork do repositório: correção e funcionalidade nova chegam nas duas ao mesmo tempo, e o dado de uma nunca encosta no da outra. A versão web está em produção. O app nativo em Flutter, que fala com um BFF fino sobre a mesma API, está em desenvolvimento e ainda não foi publicado em loja.

• Next.js
• Flutter
• Dart
• BFF REST
• PostgreSQL
• GitHub Actions
• Portainer

WhatsApp como plataforma: atendimento, campanhas e API

Plataforma de mensageria e atendimento

Problema

No Brasil boa parte do negócio acontece no WhatsApp, e é ali que o processo se perde: conversa sem histórico, campanha sem métrica e grupo de comunidade que lota e trava o crescimento. Quem opera afiliados no canal abre grupo novo na mão, gera o link e divulga, sempre atrasado.

Solução

Um painel só, com três produtos que a empresa contrata separado. CRM: contatos, funil, automação e relatório, com a central de atendimento em volta, onde fila, cargo, resposta pronta e histórico ficam no mesmo lugar. Promoções: linha de grupos de comunidade com transbordo automático, campanha que dispara sozinha na hora marcada e link rastreado até o clique. API: o mesmo WhatsApp por HTTP, com chave, cota, webhook e especificação publicada. O motor de grupos acompanha a lotação, abre o próximo da fila quando o atual enche e publica o convite sem ninguém precisar lembrar. Entrada sempre por convite, nunca por adição forçada.

Resultado

Um canal que dependia de operação manual virou produto vendido: plano e fatura, equipe por cargo, várias contas por usuário, programa de afiliados com carteira, central de ajuda, comunidade e a opção de o cliente rodar a plataforma na infraestrutura dele. Tudo com relatório e trilha de auditoria, então dá para saber o que foi enviado, por quem e o que voltou. Está nascendo em cima uma família de ferramentas de segurança, ainda em beta: conferência de cobrança PIX antes de a mensagem chegar ao atendente, vigilância de uso fora do padrão, cadeia de custódia do que entrou e saiu e rastreio de vazamento de conteúdo. Três suítes de teste automatizado, painel, ponta a ponta e motor, rodam como portão antes de cada merge, e o deploy é contínuo.

• Go
• Next.js
• PostgreSQL
• API REST
• Webhooks
• Docker

Treino, nutrição e evolução do aluno

SaaS de saúde e treinamento

Problema

Personal trainer, nutricionista e aluno trabalhando em ferramentas soltas: treino na planilha, dieta em PDF, evolução no WhatsApp. Ninguém tem a visão contínua do aluno nem consegue medir o que funcionou.

Solução

Uma plataforma com plano de treino e de nutrição, check-in, evolução, comunicação e integração com o Strava. A IA entra na montagem e no acompanhamento do plano. O aluno usa como PWA, com notificação push, sem passar por loja de aplicativos.

Resultado

Produto em operação com assinatura, pipeline de release próprio e deploy automatizado.

• Next.js
• Fastify
• Prisma
• PostgreSQL
• Better Auth
• Vercel AI SDK
• Stripe
• Docker

Digitalização do ciclo produtivo em aquicultura

Produto para aquicultura

Problema

Operação controlada em caderno e planilha. Arraçoamento, biometria, qualidade da água e custo por tanque sem rastreabilidade e sem série histórica, o que impede comparar um ciclo com o anterior.

Solução

Registro feito em campo, indicadores por lote e por tanque, histórico consultável e modelagem preparada para receber telemetria quando a instrumentação de água entrar.

Resultado

O processo passou a gerar dado consultável. Dá para comparar ciclos em vez de lembrar deles.

• Next.js
• Node.js
• Prisma
• PostgreSQL
• Docker

Séries para ler: entretenimento seriado por escrito

Plataforma B2C de conteúdo

Problema

Ficção seriada digital costuma ser vendida como livro ou como aplicativo de rolagem infinita. Faltava o formato do meio: temporada, episódio e ritmo de série, com leitura confortável no celular e assinatura que se sustenta.

Solução

Catálogo, leitor e assinatura sobre a mesma fundação técnica das outras plataformas, sem multi-tenant, porque aqui o cliente é o leitor. Um pipeline editorial próprio, de custo fixo, alimenta o catálogo com personas autorais.

Resultado

Fundação, infraestrutura e identidade definidas, com o MVP em desenvolvimento sobre a mesma máquina de deploy dos outros produtos. Infraestrutura compartilhada, banco dedicado e custo marginal baixo.

• Next.js
• Prisma
• PostgreSQL
• Stripe
• Cloudflare Tunnel
• GHCR
• Docker

A plataforma industrial que substituiu o supervisório legado

Plataforma OT/IT · desenvolvedor único

Problema

Oito plantas mediam produção e parada com um supervisório legado: lógica em VBA, gravação em arquivos Access sobre compartilhamento de rede e um MySQL sem réplica. Cada planta era uma ilha, sem histórico comparável. De cerca de 773 equipamentos, só 84 tinham estado visível ao vivo. Ociosidade, que era a dor número um da diretoria, ninguém media. E o número que existia não era confiável, o que é pior do que não ter número: a decisão se toma em cima dele do mesmo jeito.

Solução

Arquitetei e escrevi a plataforma inteira. Coleta OPC UA estritamente em leitura. SQL Server com 219 migrações versionadas, cada uma com o rollback escrito junto. Uma API em FastAPI com 68 routers e SQLAlchemy Core, com SQL explícito e revisável no lugar de ORM de entidade. E treze unidades implantáveis: quatro aplicações web, duas desktop em .NET, três coletores, observabilidade própria e o pipeline que migrou o código legado. O supervisório web tem editor gráfico próprio, com símbolos, tubulação animada, vínculo de tag, alarme, replay histórico e a função “por que parou”.

Resultado

Em produção nas oito plantas, com 529 equipamentos monitorados e cerca de 95 mil registros de métrica por dia. A restrição que desenhou tudo: fábrica não para para ser testada. Toda interação com controlador é leitura, e escrita só existe como fila auditada com lista de permissão. Liga e desliga ficaram barrados por decisão de projeto.

• OPC UA
• Python 3.12 / FastAPI
• SQLAlchemy Core
• SQL Server
• React 18 / Next.js 15
• C# .NET 8 / WPF
• Docker Swarm
• Telegraf

De 84 para 529 equipamentos com estado ao vivo

Integração OT

Problema

O serviço de navegação do controlador era incompleto: não expunha boa parte do endereçamento que existia de fato. Quem olhasse só o que o CLP listava concluiria que a fábrica tinha 84 equipamentos instrumentados, e compraria sensor para todo o resto.

Solução

Escrevi um enumerador que deriva o identificador de nó a partir da convenção de nomenclatura da engenharia e testa cada candidato contra o controlador, um a um. Nada foi presumido: cada variável entrou no catálogo porque respondeu. A sondagem tem uma armadilha que quase a invalidou. A leitura em lote devolve vazio tanto para nó inexistente quanto para nó sem valor, então ela passa toda verde e mente. Para provar ausência foi preciso ler o status de cada nó, um por um.

Resultado

Os 84 equipamentos com estado ao vivo viraram 529, com 2.016 variáveis verificadas e a leitura mantida em pouco mais de 5 mil nós por ciclo, dentro do teto de sessões do hardware. A contraprova vale tanto quanto: nos silos a mesma sondagem mostrou que nível contínuo não existe em nenhum deles, só contato de baixo, alto e cheio. Foi isso que separou o que era cadastro do que era compra de instrumento.

• OPC UA
• Python (asyncua)
• SQL Server
• Auditoria de lógica ladder

Provar que o indicador da diretoria estava errado

Engenharia de veracidade do dado

Problema

O telão mostrava uma extrusora em reforma como 98,3% disponível. A consulta derivava parada comparando cada evento do log legado com o seguinte, sem teto e sem recorte por dia: um segmento que nunca fechou somou 618 horas corridas e caiu inteiro num único dia do relatório. Junto vinha um erro mais sutil. O bit de “ligado” do CLP quer dizer painel energizado, não motor girando: um equipamento apareceu 6,4 dias ligado, atravessando um fim de semana de fábrica fechada, com a corrente do motor em 0,0 A o tempo todo.

Solução

Teto por segmento, recorte diário, limite no índice, exclusão de equipamento em manutenção e média ponderada por horas planejadas. E uma correção que não é de código: o indicador deixou de se chamar OEE e passou a se chamar disponibilidade, porque performance e qualidade não eram medidas. Chamar de OEE o que não é OEE é inventar dado. Na mesma frente caiu o campo de data que não era relógio: era o carimbo de inserção da linha, não a hora do evento. Menos de 1% das linhas inflava 13,6% de todas as horas de produção publicadas.

Resultado

Disponibilidade publicada: 35,7% virou 26,9%. Horas de produção: 21.748 h viraram 18.782 h. Todas as correções derrubaram números. Entregar um número menor e correto a quem já usava o maior só funciona com a evidência junto, e por isso cada uma virou decisão escrita, com problema, razão e resultado.

• T-SQL (funções de janela)
• SQL Server
• Python
• Views de indicador
• Decisões versionadas

O indicador que a diretoria pedia em primeiro lugar

Análise de dados industriais

Problema

Uma extrusora acumulava 198 horas de ociosidade em 30 dias, alto demais para ser verdade. Nove dos 39 intervalos batiam exatamente 12,00 h, que é de quanto em quanto tempo o coletor fechava janela, e caíam em fim de semana de fábrica fechada. O resto do problema era onde colocar o limiar que separa motor parado de motor girando em vazio.

Solução

Uma view recorta o intervalo bruto na malha real de turno, sem tocar na tabela original, e o risco residual ficou documentado em vez de escondido. O limiar veio do fundo do vale do histograma bimodal de corrente elétrica, que separa fisicamente os dois estados. Registrei também a armadilha metodológica que quase usei: “se o limiar está acima do percentil 10, é falso positivo” é circular, porque usa como referência exatamente a distribuição sob suspeita.

Resultado

Queda de 57% naquele equipamento e de 42% a 62% nos demais. No conjunto, 229,7 h viraram 162,1 h depois de calibrar os limiares. Ficou uma regra para o projeto inteiro: a saúde de uma rotina se mede pelo carimbo do dado mais recente que ela produziu, nunca pelo log. Teve rotina imprimindo “ok: 0 linhas” por 44 dias e container “no ar, zero reinícios” com metade do pipeline morto havia 65.

• SQL Server
• T-SQL
• Python
• Análise de histograma
• Telemetria de corrente

Falha e manutenção existiam no dado e morriam antes da tela

Veracidade do dado · integração OT

Problema

A linha do tempo de um equipamento pintava dois estados: ligado e desligado. Parecia completo, e não era. Falha e manutenção chegavam do chão de fábrica e eram descartadas no meio do caminho, então uma parada por defeito aparecia com a mesma cor de um equipamento simplesmente fora de turno. Quem olhava concluía que não houve falha, quando na verdade ninguém tinha perguntado.

Solução

Todos os estados passaram a chegar até a tela, cada um com a própria duração, mais um estado que faltava e que é o mais honesto de todos: sem informação. A falha deixou de ser um número e virou frase em português, com causa provável, ação sugerida e severidade. O painel antigo foi renomeado para dizer o que ele realmente mede, em vez de continuar posando de linha do tempo. Onde o acionamento publica a palavra de estado, ela é decodificada e mostrada ao vivo, com um aviso explícito na tela: o bit de falha diz que existe falha, não qual é.

Resultado

Em sete dias de um único equipamento apareceram 2,97 h em falha, distribuídas em seis eventos que antes ficavam escondidas dentro do cinza de desligado. O código de falha do fabricante estava ausente em 100% dos eventos gravados, e a resposta a isso foi registrar o instante e pedir apontamento humano com procedência, em vez de exibir um código plausível e inventado. Na mesma frente caiu outra fonte suja: 138 equipamentos estavam rotulados como um tipo de acionamento sem ter uma única variável daquele tipo, então a classificação passou a ser derivada do que dispara de fato, não do cadastro.

• OPC UA
• Python / FastAPI
• SQL Server
• React
• Decisões versionadas

Quando o identificador era, na verdade, um rótulo

Dados de produção

Problema

Buscar por lote devolvia milhares de ordens. Medido: 108 códigos distintos cobriam 24.110 ordens em cinco anos, e o mais frequente aparecia 4.469 vezes abrangendo 614 produtos diferentes. O gerador legado concatenava atributos que já tinham coluna própria e nada ali garantia unicidade. Era um rótulo ocupando o lugar de um identificador.

Solução

Formato datado em padrão GS1, gerado por sequência atômica no banco com bloqueio explícito e dimensionado para caber no campo que já existia, sem mexer em schema e sem migração de tela. Se a geração falha, a ordem não nasce com lote inventado.

Resultado

24.028 ordens retroconvertidas sem uma única duplicata, com o código antigo preservado ao lado do novo para que o histórico continue pesquisável pelos dois.

• SQL Server
• T-SQL (upsert atômico)
• Padrão GS1
• FastAPI

145 módulos legados convertidos por pipeline, não à mão

Modernização de legado

Problema

O supervisório legado guardava 82 telas gráficas com 145 módulos de VBA acessando Access por DAO e MySQL por ODBC, dentro de um acervo de mais de 1.300 arquivos de configuração, 333 telas e cerca de 73 mil linhas de VB6/VBA. Reescrever tela a tela era inviável e, pior, erraria em silêncio.

Solução

Um pipeline de três estágios. Extração: lê os arquivos binários de tela e isola o código de cada módulo que toca banco. Transformação: converte DAO para ADODB por regras, com mapeamento de tipos, troca das chamadas de conexão e de recordset, neutralização de operação de edição incompatível e injeção de funções auxiliares. Conciliação: cruza cada tabela e coluna citada no código contra o catálogo real do banco de destino, extraído ao vivo, para achar referência órfã antes de aplicar. Nada é alterado no lugar; cada etapa gera o próprio artefato, auditável.

Resultado

A conversão deixou de depender de paciência e passou a depender de regra revisável. Durante a transição, um espelho incremental MySQL → SQL Server manteve os dois mundos em sincronia, com descoberta de tabela e chave pelos metadados do próprio banco e leitura pura na origem. Hoje está aposentado: cumpriu o papel.

• Node.js
• C# / .NET 8
• VBA → ADODB
• SQL Server
• MySQL

A estação do operador como aplicação, não como Windows

Sistemas desktop corporativos

Problema

As estações de planta eram um Windows comum com atalhos. Isso quer dizer operador dentro do sistema de arquivos, login digitado com a mão suja, e suporte que precisava ir até a máquina ou abrir uma sessão paralela, que não mostra o que a pessoa está vendo.

Solução

Um terminal em .NET 8 com WPF que substitui o shell do Windows: splash, login por crachá em leitor USB e menu de aplicações. Ao lado dele, um serviço em contexto SYSTEM com protocolo próprio de captura e controle de tela, capaz de operar com a estação bloqueada. O suporte lista o parque online e entra na mesma sessão do operador, assistindo ou assumindo, sempre com permissão específica e conexão auditada.

Resultado

Identidade do chão de fábrica resolvida por crachá, sessão opaca no servidor com apenas o hash guardado, senha em argon2id e permissão por 18 capabilities granulares, uma delas isolada só para operação de CLP. Estação nova entra no parque por ticket cifrado em AES-256-GCM. Faltando segredo, o serviço se recusa a subir.

• C# / .NET 8
• WPF
• Serviço Windows (SYSTEM)
• WebView2
• argon2id
• AES-256-GCM

Pedido, catálogo e auditoria de gôndola em modo offline

Sistema comercial

Problema

O vendedor em campo alternava entre catálogo impresso, planilha de pedido e mensagem, muitas vezes sem sinal. A auditoria de ponto de venda não tinha registro confiável e o pedido era redigitado no escritório.

Solução

Uma aplicação única com clientes, catálogo, pedido, histórico e auditoria de gôndola, funcionando offline e sincronizando depois, com indicadores para a coordenação e trilha de quem alterou o quê.

Resultado

O pedido passou a nascer estruturado na origem, o que eliminou a redigitação e a conferência posterior.

• PWA
• Sync offline
• PostgreSQL
• APIs REST
• Dashboards

Transformar um Linux qualquer em infraestrutura pronta

Plataforma interna

Problema

Cada servidor novo repetia o mesmo ritual manual: Docker, proxy, certificado, backup, monitoramento, broker. Horas de configuração e nenhuma garantia de que dois ambientes ficaram iguais.

Solução

Uma CLI que prepara qualquer Linux e entrega infraestrutura reprodutível: containers, proxy e certificado, backup, monitoramento, camada de dados industriais com MQTT, OPC UA e Node-RED, e inteligência artificial local.

Resultado

Em desenvolvimento. Nasceu de subir o mesmo ambiente pela enésima vez e continuar encontrando diferenças entre eles.

• Linux
• Docker Compose
• Portainer
• Cloudflare
• Nginx
• Grafana
• Node-RED
• Ollama