Yogha Sistema
O sistema interno em que a operação de administração de imóveis de terceiros roda todo dia: unidades, proprietários, hóspedes, limpezas, chamados e um motor de processos que a própria gestão configura.
- Papel
- Desenvolvedor e consultor de IA
- Cliente
- Desde
- 2024
- Acesso
- Sistema interno, sem acesso público
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.
- Chamados com fluxo por etapas, SLA calculado automaticamente, campos que mudam por tipo de chamado e visão em Kanban, lista ou calendário.
- 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, cor por portal e a tela de 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 com Vite e Tailwind. Autenticação no AWS Cognito, arquivos no S3, publicação por GitHub Actions para EC2 no backend e Vercel no frontend.
Um motor de processos, em vez de mais uma tela por rotina
Cada rotina nova da operação — auditoria periódica de unidade, fluxo de entrada de hóspede — poderia ser uma funcionalidade codificada à mão. Em vez disso o sistema tem um motor genérico: a gestão desenha o processo, escolhe o gatilho e publica; o runtime descobre sozinho quais objetos precisa observar a partir dos próprios gatilhos. Processo novo não exige desenvolvedor.
A parte que dá liga é uma trava: no máximo uma execução ativa por processo e objeto. Sem ela o gatilho se realimentaria, porque o processo cria trabalho na mesma unidade que o disparou. Com ela, a varredura diária vira idempotente — rodar duas vezes é inofensivo. O custo da configurabilidade apareceu na prática: um estado inválido deixou execuções travadas em andamento para sempre, bloqueando novos disparos, e a correção foi passar a marcar execução totalmente falha como cancelada, com motivo, em vez de engolir o erro.
Stack
Backend
Frontend
Nuvem
Testes
Números
Números de produção registrados no repositório em 27/07/2026; contagem de permissões medida no código em 29/08/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.
Telas
Capturas de ambiente local de desenvolvimento com dados fictícios de demonstração — nenhuma tela vem de produção.