Produto próprio · SaaS · IA aplicada

Source privado · documentação pública

ALRYA

O que este produto faz

Conecta marketing, atendimento, cotação, reserva e receita para que a operação hoteleira acompanhe a jornada comercial do início ao fechamento.

Plataforma SaaS multiempresa para hotelaria que acompanha aquisição, conversa, cotação, reserva e receita em uma mesma jornada operacional.

ReactTypeScriptVitePythonFastAPIPostgreSQLNeonAlembicJWTGitHub ActionsRender

Ver case público + código no GitHub

3DProfundidade

Superfícies, arquitetura e dados organizados em planos visuais.

4DProcesso

Fluxos mostram a sequência entre entrada, decisão, execução e resultado.

5DContexto

Seção ativa, foco e interação reforçam a informação relevante sem mover o layout.

Produto em ação

Veja como a ALRYA conecta a jornada comercial.

As telas mostram como origem, conversa, cotação, reserva e receita permanecem conectadas dentro do produto.

ALRYA · o problema que resolve

Revenue Intelligence para hotelaria

Transforma conversas e campanhas dispersas em reservas e receita rastreável.

O hotel deixa de olhar WhatsApp, Instagram, anúncios, cotações e reservas como ilhas. A ALRYA conecta a jornada e mostra de onde a demanda veio, o que virou cotação, o que fechou e onde agir.

ANTESCanais separados

Marketing não sabe quais conversas e campanhas realmente geraram receita.

ALRYAConecta a jornada

Origem + conversa + cotação + reserva passam a compartilhar o mesmo contexto.

DEPOISDecisão por receita

A operação identifica canais, oportunidades e ações com impacto comercial.

ALRYA · processo da plataforma

Como a plataforma funciona

O usuário entra por um canal; a ALRYA acompanha o dado até a receita e devolve inteligência para a operação.

01 · EntradaAnúncio / WhatsApp / Instagram / Site

A plataforma registra canal, campanha e contexto de origem.

02 · ConversaChats + Assistant

A equipe atende em contexto; a IA auxilia leitura de intenção, histórico e próximos passos.

03 · DisponibilidadePMS → Rate Engine

Datas e ocupação consultam disponibilidade; o tarifário calcula regras e preço.

04 · ConversãoCotação → Reserva → Receita

A proposta vira reserva e o fechamento é conectado à origem para análise e novas ações.

OrigemCampanha identificada

ConversaIntenção registrada

ReservaFechamento associado

ReceitaAtribuição comercial

ALRYA · leitura após a conversão

ALRYA

Revenue Intelligence

Olá, quero reservar de 18 a 21/10 para 2 pessoas.

Datas e ocupação identificadas. Posso consultar disponibilidade.

Origem: Meta AdsIntenção: reserva

Conversa vira contexto

18–21 out3 noites

Hóspedes2 adultos

TotalR$ —

Disponibilidade→Tarifa→Proposta

Cotação com regra e disponibilidade

CampanhaMeta AdsReservaAssociadaReceitaRastreada

Reserva retorna para a origem

Anúncio→Conversa→Cotação→Reserva→Receita

Contexto e abordagem

O problema que orientou as decisões e a abordagem implementada.

A arquitetura e os fluxos apresentados neste case partem deste contexto e das restrições reais do produto.

Desafio

Marketing, atendimento, reservas e receita normalmente ficam distribuídos entre canais e sistemas diferentes. O desafio é preservar a origem do lead, o contexto da conversa e o resultado comercial sem misturar dados entre empresas, ao mesmo tempo em que autenticação, permissões, banco, migrations e integrações continuam coerentes em produção.

Abordagem

A plataforma foi organizada em torno de contexto compartilhado. Canal e campanha acompanham o lead; conversas concentram histórico, intenção e datas; disponibilidade vem do PMS; o Rate Engine calcula preço e regras; cotação e reserva preservam o contexto até a receita. Na base técnica, organização, empresa, papel e permissão definem o tenant, enquanto FastAPI, PostgreSQL/Neon e Alembic sustentam a operação e o deploy.

Responsabilidade

O que esteve sob minha responsabilidade.

Escopo real de atuação no projeto, separado de funcionalidades ou decisões que pertencem a fornecedores e sistemas externos.

Definir o domínio do produto e a separação entre módulos de receita, atendimento, marketing, criação, integrações, cobrança e administração.

Projetar o contexto multiempresa e o vínculo entre usuário, organização, empresa, papel e permissões.

Implementar e evoluir endpoints FastAPI, serviços, contratos de rota e regras de autenticação/autorização.

Construir e integrar a aplicação React/Vite com os fluxos do back-end e os estados de produto.

Manter migrations incrementais com Alembic e compatibilidade com PostgreSQL/Neon em produção.

Estruturar validações de backend e frontend em CI, além de diagnósticos de build e produção.

Documentar a arquitetura oficial para evitar caminhos paralelos e reduzir regressões durante a evolução do projeto.

Implementação técnica

Evidências técnicas do produto.

Tecnologias e estruturas descritas a partir do código, da configuração e da documentação dos projetos — não por barras subjetivas de habilidade.

Front-end

React · Vite · TypeScript

Aplicação web oficial, com build de produção, typecheck, lint e suíte de testes.

Back-end

FastAPI · Python

API oficial em backend/app, organizada por módulos, serviços, autenticação e contratos de rota.

Dados

PostgreSQL/Neon · Alembic

Banco relacional de produção com migrations incrementais e validação de heads do Alembic.

Multiempresa

Organization · Company · Access

Associação explícita entre usuário, organização, empresa e papel para definir o escopo de acesso.

Autorização

JWT · RBAC por módulo

Papéis como owner, admin, manager, attendant, marketing, finance e viewer participam da política de acesso.

Entrega

Render · GitHub Actions

CI, smoke tests, diagnósticos de build/produção e blueprint oficial de deploy.

Produto

10 módulos

Revenue, Chats, Assistant, Agents, Marketing, Studio, Integrations, Billing, Admin e Tracker sobre uma base comum.

Acesso

7 papéis

Owner, admin, manager, attendant, marketing, finance e viewer compõem a política de acesso multiempresa.

Fluxos principais

Como o sistema funciona na prática.

Cada fluxo é mostrado junto de uma representação visual do produto, para que arquitetura e comportamento sejam compreendidos sem depender apenas de documentação textual.

01Campanha/canal

02lead

03conversa

Lead entra com origem

F01Lead entra com origem

Fluxo 01

Lead entra com origem

Campanha/canal → lead → conversa

A oportunidade já começa associada à sua origem, permitindo que marketing e atendimento trabalhem sobre o mesmo contexto em vez de reconstruí-lo depois.

Campanha/canalleadconversa

01Mensagem

02histórico + intenção + datas

03Assistant/atendimento

Conversa vira contexto

F02Conversa vira contexto

Fluxo 02

Conversa vira contexto

Mensagem → histórico + intenção + datas → Assistant/atendimento

Chats omnichannel e Assistant concentram o que já foi dito, a intenção da pessoa, datas e próximos passos para que a equipe atenda sem perder continuidade.

Mensagemhistórico + intenção + datasAssistant/atendimento

01Datas + ocupação

02PMS

03Rate Engine

04cotação

Disponibilidade e tarifa

F03Disponibilidade e tarifa

Fluxo 03

Disponibilidade e tarifa

Datas + ocupação → PMS → Rate Engine → cotação

O PMS confirma inventário e o motor tarifário calcula preço e regras aplicáveis. A cotação nasce de disponibilidade e tarifa reais, não de uma simulação isolada.

Datas + ocupaçãoPMSRate Enginecotação

01Cotação

02reserva

03receita

04origem/campanha

Fechamento e atribuição

F04Fechamento e atribuição

Fluxo 04

Fechamento e atribuição

Cotação → reserva → receita → origem/campanha

Quando a oportunidade fecha, reserva e receita retornam à origem comercial para leitura de canal, campanha, conversão e novas ações de remarketing ou operação.

Cotaçãoreservareceitaorigem/campanha

Arquitetura do trabalho

Em vez de uma lista isolada, as decisões estruturais aparecem intercaladas com imagens e representações do sistema.

A01React, Vite e TypeScript compõem a aplicação web oficial

A02FastAPI e Python formam a API de produção, organizada em módulos, serviços e contratos de rota

ArquiteturaA01 — A02

A01

React, Vite e TypeScript compõem a aplicação web oficial.

A02

FastAPI e Python formam a API de produção, organizada em módulos, serviços e contratos de rota.

A03PostgreSQL/Neon é o banco de produção

A04Alembic mantém o versionamento do schema e o processo de deploy executa migrations antes de iniciar o serviço

ArquiteturaA03 — A04

A03

PostgreSQL/Neon é o banco de produção; SQLite fica restrito a desenvolvimento e testes conforme a documentação oficial.

A04

Alembic mantém o versionamento do schema e o processo de deploy executa migrations antes de iniciar o serviço.

A05O modelo multiempresa usa organizações, empresas e associações de acesso de usuário para estabelecer o contexto de tenant

A06Papéis e permissões controlam o acesso funcional aos módulos, com perfis administrativos, operacionais, marketing, financeiro e leitura

ArquiteturaA05 — A06

A05

O modelo multiempresa usa organizações, empresas e associações de acesso de usuário para estabelecer o contexto de tenant.

A06

Papéis e permissões controlam o acesso funcional aos módulos, com perfis administrativos, operacionais, marketing, financeiro e leitura.

A07O frontend compilado é servido pelo backend de produção e o blueprint oficial de deploy é mantido em render

ArquiteturaA07 — A07

A07

O frontend compilado é servido pelo backend de produção e o blueprint oficial de deploy é mantido em render.yaml.

Documentação técnica pública

Engenharia visível. Código proprietário protegido.

Esta superfície permite avaliar tecnicamente a ALRYA sem transformar o repositório privado em material público. Arquitetura, responsabilidades, fluxos, segurança, validação e decisões de engenharia são demonstrados; implementação interna, segredos e dados de clientes permanecem protegidos.

O repositório público também inclui exemplos de código sanitizados e testes para avaliação técnica, sem copiar a implementação de produção.

Front-end

React · Vite · TypeScript

Aplicação web oficial, com build de produção, typecheck, lint e suíte de testes.

Back-end

FastAPI · Python

API oficial em backend/app, organizada por módulos, serviços, autenticação e contratos de rota.

Dados

PostgreSQL/Neon · Alembic

Banco relacional de produção com migrations incrementais e validação de heads do Alembic.

Multiempresa

Organization · Company · Access

Associação explícita entre usuário, organização, empresa e papel para definir o escopo de acesso.

Autorização

JWT · RBAC por módulo

Papéis como owner, admin, manager, attendant, marketing, finance e viewer participam da política de acesso.

Entrega

Render · GitHub Actions

CI, smoke tests, diagnósticos de build/produção e blueprint oficial de deploy.

O que é público

Telas e comportamento do produto apresentados no case.

Stack, arquitetura de alto nível e responsabilidades técnicas.

Fluxos entre aquisição, conversa, cotação, reserva e receita.

Modelo conceitual de multiempresa, autenticação e autorização.

Estratégia de migrations, validação, CI e deploy.

Decisões e trade-offs relevantes para evolução do produto.

O que permanece privado

Código-fonte do front-end e do back-end.

Implementação detalhada das regras comerciais e do Rate Engine.

Prompts internos, configurações proprietárias de IA e automações.

Credenciais, tokens, chaves, webhooks e segredos de integração.

Dados de clientes, reservas, leads, conversas e métricas privadas.

Detalhes operacionais que ampliariam desnecessariamente a superfície de ataque.

Fluxo demonstrado publicamente

Campanha

Conversa

Contexto

Disponibilidade

Tarifa

Cotação

Reserva

Receita

O objetivo é demonstrar raciocínio de produto, arquitetura e execução sem publicar os mecanismos internos usados para implementar o trabalho.

Abrir documentação completa no GitHub

Dados, segurança e integridade

Regras que impedem o sistema de depender apenas da interface para manter isolamento, confiabilidade ou publicação correta dos dados.

A associação user_company_access possui unicidade por usuário e empresa, reduzindo duplicidade de vínculo no contexto multiempresa.

O escopo de dados depende de organization_id e company_id em entidades e fluxos que precisam ser isolados por cliente.

Papéis e permissões são resolvidos no serviço de tenant, com acesso por módulo em vez de uma autorização global única.

Segredos de produção, chaves de IA, Stripe, R2 e Meta são configurados por variáveis de ambiente e não fazem parte do conteúdo público do produto.

Migrations são tratadas como parte da entrega: mudanças de schema precisam acompanhar a versão da aplicação que as consome.

Validação e entrega

O que é verificado antes de tratar uma alteração como pronta para integração, publicação ou produção.

O back-end é validado com compileall, verificação de heads do Alembic e pytest.

O front-end passa por typecheck, lint, testes automatizados e build de produção.

O repositório contém workflows para testes, readiness, smoke de deploy e diagnósticos do ambiente de produção.

A arquitetura oficial restringe novas funcionalidades ao backend/app e ao frontend, reduzindo duplicidade de implementações.

O health check faz parte das rotas essenciais usadas para confirmar disponibilidade do serviço.

Decisões de produto e engenharia

Decisões que mudam comportamento, risco operacional ou capacidade de evolução — e não apenas preferências de estilo de código.

Adotar uma única arquitetura oficial de front-end, back-end e migrations para reduzir divergência entre protótipos e produção.

Tornar organização, empresa e papel parte explícita do domínio, em vez de depender de convenções informais de filtro.

Manter integrações externas separadas do núcleo do produto para reduzir o acoplamento a fornecedores específicos.

Executar migrations no fluxo oficial de deploy para evitar aplicação nova operando sobre schema antigo.

Tratar IA aplicada como capacidade do produto conectada a dados e regras de negócio, sem apresentar integração de API como experiência de treinamento de modelos.

Trade-offs

O benefício de uma decisão técnica sempre vem acompanhado de custo, restrição ou dependência. Estes são os compromissos mais importantes.

Servir o front-end compilado pelo back-end simplifica a operação atual e reduz superfícies de deploy, mas diminui a independência de release entre as duas camadas.

O escopo multiempresa explícito aumenta a segurança conceitual dos dados, mas adiciona complexidade a queries, serviços, testes e migrations.

Permissões por módulo permitem controle mais granular, mas exigem disciplina para que novas funcionalidades herdem corretamente o contexto de tenant.

Isolar integrações externas reduz acoplamento, porém adiciona camadas de adaptação e estados de falha que precisam ser monitorados.

O que este produto demonstra

Competências demonstradas pelas decisões, implementação e validação apresentadas neste case.

Consolida módulos de Revenue, Chats, Assistant, Agents, Marketing, Studio, Integrations, Billing, Admin e Tracker sobre uma base técnica comum.

Transforma isolamento multiempresa e permissão por papel em parte explícita do domínio, não apenas em filtros de interface.

Mantém banco, migrations, autenticação, frontend e backend dentro de um fluxo oficial de produção documentado.

Cria uma base para aplicar IA e automação em processos reais de hotelaria sem separá-las do contexto operacional do produto.

Este case foi elaborado a partir da arquitetura e do código do repositório privado. Dados de clientes, credenciais e informações proprietárias sensíveis não são expostos nesta apresentação.

Outros trabalhos

Continue pelos demais trabalhos e pela trajetória em aplicativos e inteligência artificial.

Voltar ao portfólio Case público + código Perfil no GitHub