A engenharia por trás da unificação de portais de turismo e hospitalidade

Resumo técnico do case

• Desafio: aproximar jornadas de destinos, hospedagem, conteúdo e reservas em uma plataforma com múltiplos sistemas e equipes.
• Atuação da Hit: desenvolvimento, liderança técnica, trabalho no CMS e nas integrações, qualidade, apoio de infraestrutura e continuidade da operação, em parceria com a agência responsável.
• Decisão de arquitetura: separar interface, gestão de conteúdo e motores externos de reservas, respeitando as informações realmente disponíveis nas APIs.
• Entregas documentadas: página customizada de pacote, correções de busca e publicação, estado de pacote esgotado e alteração de um motor de vendas externo, entre outras evoluções detalhadas no relato.
• Limites do relato: o texto distingue base especificada, entregas registradas e reconstruções ilustrativas; não apresenta indicadores fictícios como resultados medidos.

As seis imagens deste case são reconstruções ilustrativas, não capturas reais da plataforma. Elementos visuais e indicadores fictícios não representam resultados comerciais ou técnicos medidos.

Em parceria com uma grande agência global, a Hit Digital participou do desenvolvimento e da evolução de uma plataforma de turismo e hospitalidade, conectando interfaces, gestão de conteúdo e jornadas de reserva em uma operação com múltiplos sistemas.

Encontrar um destino, conhecer os hotéis, explorar experiências, consultar um pacote e seguir para a reserva. Para o visitante, essas ações fazem parte do mesmo planejamento de viagem. Nos bastidores, porém, elas podem depender de equipes, conteúdos e fornecedores diferentes.

Esse era o contexto do projeto: uma operação de turismo e hospitalidade que buscava aproximar suas frentes digitais em uma plataforma centralizada. O planejamento original tinha como objetivo reunir nove portais e áreas digitais, com jornadas que passavam por destinos, hospedagem, lazer, conteúdo editorial e relacionamento.

A Hit entrou nessa iniciativa como parceira técnica de uma agência global. Nossa participação envolveu desenvolvimento, liderança técnica, trabalho no CMS e nas integrações, qualidade, apoio de infraestrutura e continuidade da operação após a etapa inicial.

O trabalho não se resumia a colocar páginas sob o mesmo endereço. Era necessário conectar o que o visitante via com o que a operação precisava administrar e com o que os sistemas externos realmente conseguiam oferecer.

O desafio: uma experiência integrada sobre uma operação distribuída

A centralização da presença digital tinha um objetivo de negócio claro: aproximar descoberta, informação e intenção de reserva, além de dar mais autonomia às equipes responsáveis pelo conteúdo.

O escopo reunia necessidades diferentes. Uma página de destino precisava contextualizar a viagem. A apresentação de um hotel precisava organizar informações sobre acomodação e experiências. Uma página de pacote tinha uma função comercial mais direta. Blog, eventos e atendimento acrescentavam outras formas de interação.

Essas diferenças apareciam na implementação. O acompanhamento de desenvolvimento contemplava menus, galerias, carrosséis, ofertas, listagens, buscas, filtros, formulários, páginas internas e componentes de programação. Cada família de páginas tinha seus conteúdos, integrações e dependências.

A autonomia editorial também era uma prioridade. O novo CMS deveria permitir que marketing e vendas administrassem páginas, imagens, banners e conteúdos promocionais sem transformar toda atualização em uma nova demanda de desenvolvimento.

O desafio era conciliar essas duas perspectivas: oferecer uma navegação coerente para o público e uma estrutura administrável para quem operava o portal.

A participação da Hit dentro da equipe do projeto

A iniciativa foi conduzida em uma operação compartilhada. A agência parceira reunia frentes de estratégia, criação, experiência, conteúdo e gestão, enquanto diferentes especialistas participavam da construção técnica.

A Hit contribuiu com liderança técnica, desenvolvimento e qualidade, além de acompanhamento de projeto e atuação em infraestrutura conforme a evolução do escopo. Havia responsabilidades distribuídas para revisão de código, integração de componentes, validação de telas, preparação de ambientes e implantação.

Esse modelo exigia alinhamento contínuo. Uma interface podia depender de um campo ainda em preparação no CMS. Uma integração precisava de informações de outro fornecedor. Uma publicação envolvia validações e pessoas diferentes das responsáveis pela implementação inicial.

Nossa atuação estava nessa continuidade entre as partes: desenvolver, esclarecer dependências, apoiar decisões técnicas e acompanhar a evolução das entregas junto à agência.

Nosso papel era contribuir com engenharia e capacidade de execução, em colaboração com as equipes responsáveis pela estratégia, pelo design e pelos sistemas comerciais envolvidos.

A base tecnológica: interface, conteúdo e reservas com responsabilidades distintas

A base especificada para o projeto combinava Vue.js e TypeScript no front-end, Directus como CMS headless e MySQL para o banco de dados. A frente de infraestrutura também contemplava Nuxt com renderização no servidor, ou SSR, e hospedagem na AWS.

A organização distinguia a apresentação ao visitante, a administração de conteúdo e os sistemas responsáveis pelas reservas.

O Directus ocupava uma posição importante nessa composição. Como CMS headless, separava a administração do conteúdo da interface apresentada ao público. Isso permitia trabalhar as estruturas editoriais e sua integração com as páginas sem tratar o painel administrativo como o próprio site.

Já a reserva tinha outra responsabilidade. Na primeira fase, o portal não substituía os motores transacionais existentes por um e-commerce próprio. A experiência comercial precisava se conectar a esses sistemas, respeitando seus recursos e limitações.

Essa separação ajudava a delimitar o trabalho: apresentar uma oferta, administrar seu conteúdo e concluir uma reserva eram partes relacionadas, mas não equivalentes.

Directus: a engenharia também estava no trabalho de quem publica

A experiência do visitante era apenas uma das interfaces do projeto. A outra era o ambiente utilizado por quem precisava manter o portal atualizado.

O planejamento do CMS abrangia conteúdos dinâmicos, páginas promocionais, biblioteca de mídia, formulários, permissões e agendamento de publicações. Esses requisitos traduziam uma necessidade prática: dar à operação ferramentas para trabalhar conteúdos de naturezas diferentes dentro da mesma plataforma.

Uma página de hotel e uma página de pacote, por exemplo, não cumprem a mesma função. Ainda que compartilhem elementos visuais, a organização das informações e sua ligação com a jornada de reserva exigem tratamento próprio.

Ao longo do trabalho, a atuação no Directus incluiu ajustes de campos, publicação, permissões e integração com componentes do front-end. Na etapa de evolução, foram concluídas entregas como a criação de página customizada de pacote e correções no funcionamento da publicação.

Também houve trabalho em campos de edição de pacotes e em componentes de conteúdo. Isso demonstra uma parte importante da construção: fazer com que a estrutura utilizada pelos editores correspondesse ao que a aplicação precisava apresentar.

A autonomia editorial era um objetivo de arquitetura e de produto. Para sustentá-la, não bastava disponibilizar um painel: era necessário trabalhar o caminho entre edição, conteúdo armazenado e exibição no portal.

Integração com motores de reservas: o requisito precisava encontrar a realidade das APIs

Uma das partes mais relevantes do projeto estava na relação entre a experiência comercial e os sistemas externos de reservas.

O requisito de negócio buscava apresentar preços e disponibilidade atualizados. Na análise técnica, porém, apareceram limitações concretas: as APIs disponíveis não forneciam todas as informações de hospedagem imaginadas inicialmente. Na configuração descrita para essa etapa, o calendário do fornecedor era o componente que apresentava informações atualizadas de preço e disponibilidade.

Para os pacotes, a documentação considerava cadastro no CMS e obtenção de informações a partir de páginas ou URLs dos fornecedores. A execução também incluiu trabalho com um scraper para atualização de preços, além de ajustes posteriores relacionados ao intervalo de atualização.

Isso exigia distinguir duas coisas que podem parecer iguais em uma apresentação comercial: ter uma conexão com um fornecedor e ter acesso a todos os dados necessários para uma funcionalidade.

Uma apresentação comercial no portal, com reserva em ambiente externo

A experiência de pacotes previa categorização e filtros, incluindo diferenças entre produtos com e sem transporte aéreo. O usuário poderia explorar a oferta no portal e, na sequência, seguir para o ambiente externo responsável pela reserva.

Portanto, havia trabalho de desenvolvimento mesmo sem construir um checkout próprio. Era preciso organizar o conteúdo, implementar os componentes da jornada e conectá-los ao destino comercial correspondente.

Na sustentação, duas entregas ilustram essa frente: a correção da busca de hotel com aéreo e a alteração do motor de vendas de uma operação de lazer para outro fornecedor. Ambas tiveram conclusão e implantação em produção registradas.

Adaptar a solução sem ampliar artificialmente sua promessa

As limitações das APIs fizeram parte da definição da solução. Nem toda informação estava disponível da forma desejada, e nem toda funcionalidade poderia depender de uma integração ainda não oferecida pelo sistema externo.

A resposta técnica precisava levar essas condições em conta. Em alguns pontos, o CMS sustentava a informação editorial. Em outros, a experiência utilizava componentes do fornecedor. A atualização de pacotes também envolvia rotinas específicas de coleta de dados.

A decisão importante era definir de onde cada informação poderia vir e como ela participaria da experiência, sem tratar todos os fornecedores como se disponibilizassem o mesmo conjunto de recursos.

Front-end e qualidade: olhar para o comportamento, não apenas para o layout

O desenvolvimento contemplava páginas e componentes com funções bastante diferentes. Menus e buscas orientavam a navegação. Galerias e conteúdos ajudavam na exploração. Pacotes e componentes de reserva aproximavam o visitante de uma decisão comercial.

A integração entre interface e CMS era uma frente recorrente no acompanhamento técnico. Uma seção podia ter sua apresentação visual adiantada e ainda depender de conteúdo estruturado, conexão de dados ou validação de qualidade.

Por isso, a revisão não se encerrava na aparência da página. O trabalho precisava considerar o comportamento do componente no fluxo em que ele seria usado e sua relação com o restante da plataforma.

A evolução em produção trouxe exemplos objetivos: ajustes na busca de hotel com aéreo, implementação de um estado de pacote esgotado e refinamentos em abas e modais de conteúdo.

São entregas de naturezas diferentes. A busca participa do planejamento de compra. O estado de esgotado comunica uma condição da oferta. Um modal organiza uma interação localizada. Tratá-las individualmente permitia direcionar desenvolvimento e QA para o problema correspondente.

Migração de conteúdo e URLs: o lançamento começava antes da publicação

Unificar frentes digitais também exigia lidar com a estrutura anterior dos portais.

O planejamento de migração contemplava levantamento de URLs e definição de redirecionamentos. No acompanhamento técnico, a revisão de SEO e o redirecionamento das URLs antigas foram explicitados como condições para o lançamento.

Essa preocupação fazia parte do projeto desde sua concepção. A mudança de organização das páginas precisava considerar os caminhos já existentes, e não apenas a navegação desenhada para o novo ambiente.

Havia ainda outra coordenação necessária: a evolução do sistema acontecia em paralelo à preparação e ao cadastro de conteúdo.

A passagem técnica descrevia um procedimento envolvendo o banco de homologação, a estrutura de dados de desenvolvimento, combinação das alterações e validação. O processo também previa uma janela de congelamento de conteúdo para coordenar as intervenções.

O ponto central era administrar duas mudanças simultâneas: o que a plataforma conseguia representar e o que a equipe já estava inserindo nela.

Nesse contexto, migrar não significava simplesmente copiar arquivos. Significava coordenar estrutura, conteúdo, endereços e responsáveis antes de colocar uma nova versão à disposição do público.

Infraestrutura e publicação: uma frente própria de engenharia

Ao longo do projeto, foi formalizada uma frente específica para setup da aplicação na AWS, incluindo ambientes de homologação e produção e processos de implantação.

Esse escopo contemplava pipelines com GitHub Actions e CDK para Nuxt e Directus, além de serviços como ECS Fargate, ECR, RDS, S3, ALB e CloudFront. Também incluía configuração de proteção, monitoramento, alertas, políticas de backup e recuperação de desastre.

Esses elementos compunham a especificação de infraestrutura. No trabalho operacional, a participação técnica alcançou preparação de ambientes, apoio a deploys e tratamento de questões de pipeline, cache e permissões.

A distribuição de responsabilidades também era explícita. O acompanhamento registrava quem poderia aprovar alterações de código, quem realizaria publicações em cada ambiente e quem deveria ser acionado para questões de infraestrutura.

Essa organização importava porque o desenvolvimento não era executado por uma equipe isolada. A passagem de uma alteração para homologação e produção dependia de coordenação entre pessoas, ambientes e validações.

Entregas que chegaram à produção

A etapa de evolução permite observar o projeto por meio de entregas concretas, além do escopo original.

Os controles de execução registram itens concluídos com implantação em homologação e produção. Entre eles estão:

A continuidade do trabalho também incluiu a implementação de llms.txt e ajustes em seu campo de edição no CMS. Trata-se de uma entrega técnica específica; não a utilizamos como indicador de ganho de visibilidade em ferramentas de IA.

Esses exemplos mostram a abrangência da atuação. A mesma plataforma exigia trabalho sobre conteúdo, navegação, integração comercial e operação técnica, com cada demanda acompanhada conforme sua natureza.

Sustentação com desenvolvimento, QA e liderança técnica

A participação da Hit continuou em um modelo de sustentação que combinava desenvolvimento fullstack, qualidade e liderança técnica.

A operação foi organizada com tickets, estimativas submetidas à aprovação, agrupamento de demandas em sprints e coordenação de janelas de publicação em homologação e produção. O objetivo era dar visibilidade ao trabalho antes e durante a execução.

O acordo dessa etapa incluía retorno de estimativas em até 24 horas. Esse prazo dizia respeito à avaliação da demanda, não à promessa de resolver qualquer ocorrência dentro do mesmo intervalo.

Para atividades estimadas acima de seis horas, foi definido um checkpoint na metade da execução. A checagem deveria confirmar o andamento e verificar se a entrega permanecia dentro da estimativa aprovada.

Esse acompanhamento ajudava a organizar uma operação em que conviviam novas funcionalidades, correções e ajustes técnicos. Uma demanda de conteúdo não tinha o mesmo percurso de uma mudança de integração ou de uma investigação de infraestrutura.

A presença de desenvolvimento, QA e liderança técnica no modelo permitia distribuir essas responsabilidades sem tratar a sustentação como uma sequência indiferenciada de pequenas alterações.

Evoluir por etapas também fazia parte da solução

O planejamento mais amplo incluía funcionalidades de relacionamento, área logada, fidelização, tradução e personalização. Algumas dependiam de definições adicionais do cliente ou de informações disponibilizadas por outros sistemas.

A condução do projeto distinguia essas frentes das entregas que podiam avançar em cada etapa. Em uma das aprovações posteriores, por exemplo, manutenção e planejamento de viagem foram tratados separadamente da área logada, que ainda dependia de definições.

Esse recorte é relevante para entender a iniciativa. Uma plataforma pode reunir uma visão ampla de evolução sem que todas as funcionalidades tenham a mesma maturidade de requisitos e integração no mesmo momento.

Neste case, o foco está na participação técnica e nas entregas de interface, CMS, integração e sustentação efetivamente registradas, sem apresentar todo o planejamento futuro como funcionalidade concluída.

O resultado: entregas técnicas e continuidade de operação

A contribuição da Hit se materializou no desenvolvimento e na evolução da plataforma, com entregas específicas em produção e atuação contínua sobre a experiência, o conteúdo e suas conexões técnicas.

O trabalho reuniu frentes que precisam funcionar em conjunto: interfaces com comportamentos próprios, um CMS utilizado pela operação, jornadas ligadas a motores de reservas e processos de qualidade e publicação.

A ampliação de vendas diretas, a melhoria da conversão e a preservação da presença orgânica faziam parte dos objetivos de negócio da iniciativa. Os resultados apresentados aqui, porém, são técnicos e operacionais. Não atribuímos à atuação números de receita, reservas ou tráfego sem uma medição específica que os sustente.

O que este projeto demonstra é a capacidade de participar de uma operação com múltiplas dependências e continuar trabalhando sobre ela depois da implementação inicial. A entrega de uma página, a adaptação de uma integração e a resolução de um problema de publicação são partes diferentes desse mesmo compromisso.

Quando o projeto exige mais do que desenvolvimento de páginas

O visitante não precisa conhecer o CMS, a API do motor de reservas ou o processo de publicação. Mas sua experiência depende das decisões tomadas nessas camadas.

Neste projeto, a Hit participou justamente dessa conexão: transformar requisitos e layouts em implementação, trabalhar as fronteiras entre sistemas e acompanhar a plataforma durante sua evolução.

Para a agência parceira, nossa contribuição esteve na capacidade de desenvolvimento acompanhada de liderança técnica, qualidade e apoio à operação. Para o projeto, isso significou uma equipe atuando tanto nas entregas visíveis quanto nas dependências necessárias para colocá-las em funcionamento.

Sua agência precisa de uma parceira técnica para desenvolver uma plataforma, conectar sistemas ou sustentar uma operação digital? Converse com a Hit Digital sobre desenvolvimento white label e projetos sob medida.

Confidencialidade: a Hit Digital atua de forma discreta, no modelo white label, em projetos viabilizados por agências parceiras. Para preservar a confidencialidade dessas relações, o cliente final e a agência não são identificados neste case.