Projeto de desenvolvimento web · Hospitalidade · Turismo
Source privado · documentação públicaO que este site faz
Desenvolvimento do site para apresentar duas casas de temporada independentes, explicar capacidade e estrutura e conduzir o visitante à solicitação de reserva.
Site e base digital para apresentar duas casas de temporada independentes em Pirenópolis e conduzir o visitante até uma solicitação de reserva.
Superfícies, arquitetura e dados organizados em planos visuais.
Fluxos mostram a sequência entre entrada, decisão, execução e resultado.
Seção ativa, foco e interação reforçam a informação relevante sem mover o layout.
Site em ação
As telas mostram como o site apresenta as duas casas, organiza a decisão e conduz o visitante até a solicitação de reserva.
Pirenópolis · Goiás
Solar dos Pireneus
Pirenópolis em outro ritmo.
Entre a tranquilidade do Cerrado e a proximidade de Pirenópolis, um lugar para reunir quem você gosta e aproveitar cada momento.
Até 8 hóspedesCasa SolarAconchego, autonomia e lazer privativo.
Até 25 hóspedesCasa TaperaMais espaço para famílias, amigos, equipes e grupos.Escolha as datas e continue para a solicitação de reserva.
Contexto e abordagem
A arquitetura e os fluxos apresentados neste case partem deste contexto e das restrições reais do produto.
Desafio
O visitante precisa entender rapidamente qual casa atende ao seu grupo, o que cada espaço oferece e como solicitar a estadia. Ao mesmo tempo, o sistema não pode prometer disponibilidade, pagamento ou confirmação que ainda dependem de tratamento posterior, nem expor dados pessoais enviados por hóspedes.
Abordagem
A experiência separa apresentação e operação. Conteúdo publicado descreve casas, estrutura, ofertas e destino; o formulário registra pedido de reserva com contexto da estadia e origem da campanha; RLS impede leitura pública dos dados enviados; published/noindex controla o que pode ser exposto e indexado. Assim, a Fase 1 funciona como site comercial sem fingir ser um PMS ou motor de pagamento.
Responsabilidade
Escopo real de atuação no projeto, separado de funcionalidades ou decisões que pertencem a fornecedores e sistemas externos.
Projetar a Fase 1 para funcionar como site público sem bloquear a evolução futura para um painel administrativo autenticado.
Modelar acomodações, conteúdo editorial, mídia, ofertas, avaliações, cardápio, configurações, pedidos de reserva e leads.
Separar solicitação de reserva de confirmação real, evitando prometer disponibilidade ou pagamento que o sistema ainda não processa.
Aplicar Row Level Security para leitura pública, submissão anônima e acesso interno a dados sensíveis.
Construir SEO administrável por banco, com published/noindex, metadata e sitemap/robots dinâmicos.
Preservar UTMs, origem, referrer e dispositivo nos pedidos e leads para futura análise de aquisição.
Documentar dependências de mídia e riscos de migração antes de desligar a infraestrutura antiga.
Implementação técnica
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.
Frontend
Aplicação TypeScript com Tailwind CSS 4, TanStack Query e Vite.
Dados
Conteúdo, mídia, acomodações, ofertas, reservas e leads compartilham a mesma fonte de verdade.
Segurança
Políticas distinguem conteúdo público, inserts anônimos e leitura de dados sensíveis por equipe autenticada.
Conversão
Pedidos e contatos preservam contexto de campanha e origem sem serem tratados como confirmação automática.
SEO
Indexação e metadados podem acompanhar o estado editorial real de cada conteúdo.
Fluxos principais
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.
Solicitação de reserva
Fluxo 01
Datas + hóspedes + casa → validação → pedido recebido
O visitante informa o contexto da estadia e envia uma solicitação. O sistema confirma o recebimento, não disponibilidade garantida, pagamento ou reserva confirmada.
Conteúdo só quando validado
Fluxo 02
Conteúdo → published/noindex → página pública → SEO
Informações provisórias podem permanecer no banco sem aparecer para o visitante ou mecanismos de busca até que estejam prontas para publicação.
Dados protegidos após o envio
Fluxo 03
Visitante envia → RLS permite insert → leitura pública bloqueada → equipe acessa
Pedidos e leads entram no sistema sem conceder ao visitante acesso à lista ou aos dados pessoais de outras pessoas.
Em vez de uma lista isolada, as decisões estruturais aparecem intercaladas com imagens e representações do sistema.
TanStack Start, React 19, TypeScript e Tailwind CSS 4 formam a aplicação web.
Supabase/Lovable Cloud centraliza conteúdo, acomodações, mídia, ofertas, avaliações, cardápio, configurações, pedidos e leads.
Row Level Security separa leitura pública, submissão anônima e acesso interno autenticado.
Migrations incrementais em supabase/migrations versionam o schema e as políticas de acesso.
SEO por banco controla título, descrição, imagem social, published e noindex em diferentes entidades.
Pedidos de reserva armazenam dados da estadia, hóspede, acomodação, oferta/cupom e atribuição de marketing.
Documentação técnica pública
O showcase do Solar dos Pireneus apresenta a arquitetura do site, o fluxo de solicitação de reserva, SEO, modelagem de dados e segurança por RLS sem publicar o repositório de produção ou dados pessoais enviados pelos visitantes.
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.
Frontend
Aplicação TypeScript com Tailwind CSS 4, TanStack Query e Vite.
Dados
Conteúdo, mídia, acomodações, ofertas, reservas e leads compartilham a mesma fonte de verdade.
Segurança
Políticas distinguem conteúdo público, inserts anônimos e leitura de dados sensíveis por equipe autenticada.
Conversão
Pedidos e contatos preservam contexto de campanha e origem sem serem tratados como confirmação automática.
SEO
Indexação e metadados podem acompanhar o estado editorial real de cada conteúdo.
Estrutura das páginas e apresentação das duas casas.
Fluxo de solicitação de reserva e contexto de estadia.
Arquitetura TanStack Start, React, TypeScript e Supabase.
Estratégia de conteúdo publicado, noindex e SEO.
Modelo conceitual de booking requests, leads e atribuição.
Uso de RLS para separar conteúdo público e dados sensíveis.
Código-fonte da aplicação e migrations completas.
Políticas internas e detalhes de implementação de RLS.
Credenciais, service role, tokens e configurações de ambiente.
Dados pessoais de leads e solicitações de reserva.
Informações operacionais ainda não publicadas pelos proprietários.
Dependências administrativas e integrações internas.
Fluxo demonstrado publicamente
O objetivo é demonstrar raciocínio de produto, arquitetura e execução sem publicar os mecanismos internos usados para implementar o trabalho.
Regras que impedem o sistema de depender apenas da interface para manter isolamento, confiabilidade ou publicação correta dos dados.
Papéis internos previstos incluem admin, reservas, marketing, restaurante e proprietário.
Conteúdo público é lido mediante políticas de publicação; registros provisórios podem permanecer no banco sem exposição pública.
Visitantes anônimos podem inserir booking_requests e leads, porém não recebem permissão para listar ou ler os registros após a gravação.
Credencial service_role não deve ser exposta no frontend; apenas chaves apropriadas ao cliente podem fazer parte do ambiente público.
Preço, telefone, horário, capacidade, camas, metragem, avaliações e políticas não podem ser preenchidos por suposição.
Migrations já aplicadas não são reescritas; mudanças de schema devem seguir por migrations incrementais.
O que é verificado antes de tratar uma alteração como pronta para integração, publicação ou produção.
Lint e build fazem parte da validação mínima do projeto.
O modelo de dados e as políticas RLS são documentados separadamente para revisão de segurança e manutenção.
O estado de publicação usa published/noindex para impedir indexação prematura de conteúdo ainda em validação.
A documentação operacional registra dependências de mídia e etapas necessárias antes de desligar a infraestrutura anterior.
Decisões que mudam comportamento, risco operacional ou capacidade de evolução — e não apenas preferências de estilo de código.
Usar o mesmo banco para o site público e a futura operação interna, reduzindo duplicação de fonte de verdade.
Tratar pedido de reserva como solicitação, e não como reserva confirmada, enquanto disponibilidade e pagamento não fazem parte desta fase.
Usar RLS como fronteira de segurança no banco em vez de depender apenas de ocultação na interface.
Manter conteúdo não validado como oculto ou noindex em vez de completar lacunas com dados inventados.
Versionar mudanças de banco com migrations incrementais para preservar rastreabilidade do schema.
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.
Centralizar conteúdo e reservas no Supabase acelera a evolução da plataforma, mas exige políticas RLS corretas para cada nova tabela ou fluxo.
Manter pedidos sem confirmação automática reduz complexidade e risco operacional na Fase 1, porém exige tratamento humano posterior.
Controlar indexação por registro melhora segurança editorial, mas aumenta a disciplina necessária antes do lançamento público.
Depender temporariamente de mídia hospedada em infraestrutura antiga simplifica a transição, mas cria uma etapa obrigatória de migração antes do desligamento definitivo.
Competências demonstradas pelas decisões, implementação e validação apresentadas neste case.
Conecta conteúdo institucional, acomodações, experiências, ofertas, gastronomia, reservas e leads a uma fonte de dados compartilhada.
Prepara a Fase 1 para evoluir em direção a uma operação interna sem reconstruir todo o modelo de conteúdo e reservas.
Transforma publicação e indexação em estados controláveis por banco, evitando expor conteúdo ainda não validado.
Preserva origem de aquisição em booking_requests e leads por UTMs, landing page, referrer e dispositivo.