Projeto · 2026
Dashboards Administrativos em .NET
Plataforma de dashboards administrativos de uma instituição de ensino superior — .NET 10 + React 19 sobre Postgres, lendo o CRM e o sistema acadêmico — cujo coração é um snapshot diário que cria a fonte histórica que o ERP não tem.
O ERP e o BI respondem uma pergunta só: "quanto é hoje?". Ninguém sabia dizer quantas matrículas existiam seis meses atrás. A plataforma fotografa o dia, todo dia — e a pergunta passa a ter resposta para sempre.
A terceira plataforma que construo para a mesma operação — depois do CRM (Node.js) e da plataforma de dados (Fabric) — e a primeira em .NET: uma API em .NET 10 (C#, EF Core, PostgreSQL) com SPA em React 19, começada em agosto de 2026, com mais de 180 commits nas duas primeiras semanas.
O problema que a justifica: as consultas do ERP e o BI refletem só o estado corrente — a pergunta "quantas matrículas tínhamos em março?" não tinha resposta em lugar nenhum. Um job fotografa o dia fechado, na madrugada seguinte (00:30), e grava a série no Postgres: a foto de captação já roda em produção com backfill, e a de matrículas e financeiro nasce atrás de um gate — nada é capturado antes de as definições serem validadas com as áreas. É a fonte histórica de verdade, desenhada para alimentar CRM, marketing, comercial e financeiro.
As regras de produto estão escritas num glossário feito para quem usa as telas — e valem antes de qualquer dado capturado: traço não é zero ("—" significa "não sabemos"; R$ 0,00 significaria "custou nada", o que seria mentira); todo corte de data é no fuso local; e cada número tem uma fonte só, declarada — são três fontes que não conversam entre si: o CRM em leitura pura, o sistema acadêmico via API tipada e as plataformas de anúncio. Sem join mágico entre mundos.
A arquitetura é simples de propósito, e isso está escrito como regra no próprio repositório: projeto único, sem camadas DDD; endpoints como classes estáticas sob /api; snake_case por convenção no EF Core; SSO Google emitindo JWT. Nada acessa o Oracle direto — o acadêmico só entra pela API. E nenhum dado começou a ser capturado antes de as definições serem validadas com as áreas.
Em números
- 180+
- Commits em 2 semanas
- 00:30
- A foto do dia fechado
- 3
- Fontes, nunca misturadas
- — ≠ 0
- Regra nº 1 do glossário
Decisões de engenharia
- 01
A foto que o ERP não tira
A descoberta que definiu o desenho: as consultas de status do ERP refletem o estado corrente, não o de uma data passada — histórico retroativo só é reconstruível a partir das tabelas de movimento datadas. Por isso a plataforma não promete o impossível: fotografa cada dia fechado daqui pra frente e reconstrói do passado apenas o que as tabelas de movimento sustentam. Até o horário da foto é decisão revisada: o desenho dizia 23:50, e virou 00:30 da madrugada seguinte — porque os dez minutos finais do dia, perdidos na foto, seriam perdidos para sempre. Tudo documentado antes do primeiro byte capturado.
- 02
Traço não é zero
Traço quer dizer "não sabemos"; zero quer dizer "sabemos, e deu zero". A tela nunca troca um pelo outro: toda conta que teria divisão por zero devolve "—". Um custo por lead de R$ 0,00 afirmaria que cada lead custou nada — e a plataforma não afirma o que não sabe. É a mesma disciplina de honestidade dos números que carrego do CRM, agora como regra de produto escrita.
- 03
Cada número com uma fonte só
Três fontes alimentam a plataforma — o CRM (leitura pura, sem escrita), o sistema acadêmico (só via API tipada, nunca o Oracle direto) e as plataformas de anúncio — e elas não conversam entre si. Cada métrica declara de qual fonte vem, e nenhuma tela soma mundos diferentes num número só. Matrícula é dado confirmado do acadêmico; lead é dado do CRM; e a série histórica nasce do snapshot, separada de todas.
- 04
Simples de propósito
Projeto único, sem módulos nem DDD — e os anti-padrões estão escritos no repositório para continuar assim: não criar camadas, não usar cor crua fora dos tokens de design, não pular o prefixo /api, não consultar o Oracle direto. Uma plataforma que nasce com as regras de manutenção documentadas envelhece muito mais devagar.
Arquitetura
Fontes
CRM · API do acadêmico
Mongo em leitura pura e cliente HTTP tipado — nunca o Oracle direto.
API .NET 10
Endpoints sob /api
C# com EF Core e snake_case; SSO Google emitindo JWT.
Snapshot
A foto das 00:30
Job diário fotografa o dia fechado e grava a série histórica no Postgres.
SPA React 19
TanStack Router & Query
Zustand, Tailwind 4 e tokens de design herdados do design system da casa.
Stack