Yogha Sistema
O sistema interno de uma administradora de imóveis de terceiros: unidades, proprietários, hóspedes, calendário de ocupação, limpezas com evidência e um motor de processos que a própria gestão configura.
- Papel
- Desenvolvedor e consultor de IA (PJ): a base do backend atual e o assistente de IA; evolução em dupla com o cliente
- Cliente
- Usuários
- 14 usando o sistema
- Sistema atual desde
- março de 2026
- Acesso
- Sistema interno, código privado
Números
Números de produção registrados no repositório em 27 e 29/07/2026; contagem de permissões medida no catálogo do código em 22/09/2026. O ganho de desempenho veio de trocar a listagem completa por um modo resumido — o corte anterior de 100 registros escondia 394 das 494 unidades. O trabalho é em dupla com o próprio cliente, que também commita: 180 dos 434 commits do backend são meus.
O problema
A Yogha administra empreendimentos e unidades habitacionais que não são dela, e cada parte da operação — limpeza, manutenção, atendimento, check-in, repasse ao proprietário — vivia num lugar diferente. A documentação do projeto é direta sobre o objetivo: substituir planilhas, sistemas separados e processos manuais por uma ferramenta integrada.
O que a operação não tinha era memória: quem fez o quê, quando, e com qual evidência. Boa parte do trabalho foi transformar rotina combinada de boca em processo que o sistema dispara, cobra e registra.
O que faz
- Cadastro central de empreendimentos, unidades habitacionais com cômodos e inventário, proprietários, hóspedes e usuários.
- Central de tarefas da operação: subtarefas, anexos, histórico e comentários com menção, ao lado de um inbox interno do time.
- Motor de processos configurável: a gestão desenha o fluxo numa tela, publica, e o sistema passa a criar as tarefas sozinho.
- Calendário de ocupação no estilo dos sistemas hoteleiros, com empreendimentos recolhíveis e cor por portal, e uma tela à parte com as chegadas e saídas do dia.
- Limpeza e checkout com evidência: vídeo do estado da unidade, checklist de conservação com fotos e conferência do inventário.
- Permissões granulares por seção e ação, com trilha de auditoria, e um assistente de IA que age pelas mesmas regras de permissão e pede confirmação antes de escrever.
Como foi construído
Backend Node com TypeScript estrito, Express, Prisma e PostgreSQL na Neon, organizado em Clean Architecture com dependência em sentido único (domínio → casos de uso → adaptadores → rotas). Frontend React em JavaScript com Vite e Tailwind. Autenticação no AWS Cognito, arquivos no S3, e os dois lados publicados por GitHub Actions numa EC2 atrás do Nginx.
Endurecer o motor de processos: a trava e as execuções zumbis
O sistema tem um motor genérico de processos: a gestão desenha o processo, escolhe o gatilho e publica, sem desenvolvedor no meio. O motor é, na maior parte, código do cliente, com quem o sistema é feito em dupla; a varredura diária também é do cliente.
A minha parte foi fazer os gatilhos dispararem por evento em todas as entidades e endurecer o motor. Extraí para um módulo compartilhado a trava de uma execução ativa por processo e objeto, e passei a aplicá-la também no início manual — em produção havia três execuções ativas da mesma unidade abertas por engano. E corrigi as execuções zumbis: quando todos os blocos falhavam, a execução ficava em andamento para sempre e, pela trava, bloqueava novos disparos; agora ela encerra como cancelada, com motivo, em vez de engolir o erro. A varredura passou a ser paginada.
Stack
Backend
Frontend
Nuvem
Testes
Telas
Capturas de ambiente local de desenvolvimento com banco semeado por dados fictícios: nomes de hóspedes e de equipe inventados, sem CPF nem telefone. Nenhuma tela vem de produção.