Plataforma de terapia sob demanda — camada de landing pages

Uma plataforma de terapia sob demanda precisava de uma face pública para três públicos diferentes: o paciente que procura uma sessão hoje à noite, o profissional decidindo se leva a plataforma a sério, e o comprador de RH avaliando a coisa como benefício para os funcionários. Três landing pages, três argumentos diferentes, um mesmo produto por trás.

Trabalho de agência na Spaceapps. A relação com o cliente era da agência e eu entreguei como funcionário, entrando depois que o design do produto já estava pronto. O aplicativo em si — suas telas, suas superfícies de papel e a discovery que as gerou — é trabalho do líder técnico. A minha etapa era a camada de landing pages, e este estudo de caso trata apenas dessa camada.

Três públicos, três argumentos

A tentação num projeto assim é uma landing page só, com três abas. Não funciona, porque os três leitores não compartilham a mesma pergunta. O paciente quer saber em quanto tempo alguém fala com ele e se será alguém de verdade. O profissional quer saber de volume de atendimento, de pagamento e se a plataforma vai concorrer com o consultório dele. O comprador de RH quer cobertura, relatório e um número que ele consiga defender numa reunião de orçamento. Isso não são três tons de uma página; são três páginas.

👥3

landing pages por público

📐3

breakpoints construídos — 1440, 1280, 375

🖼️6

estados de página desenhados — em 1280 e 375

🔁2

builds — Vite, depois Next.js

• Paciente — o caminho mais curto entre chegar e falar com alguém, com o peso do acolhimento carregado pela página e não por um formulário.
• Profissional — o lado da oferta, que é uma página de recrutamento fingindo ser página de marketing e precisa responder dinheiro e autonomia antes de qualquer outra coisa.
• RH corporativo — o comprador que não é o usuário, avaliando em nome de funcionários que nunca vão ver esta página.

Wireframe, design e código pela mesma pessoa

Cada página passou por wireframe, depois design, depois código: seis estados desenhados em três públicos, em 1280 e 375, e depois uma camada construída que se adapta a 1440, 1280 e 375. Esta é a evidência de responsividade mais forte do meu portfólio, e vale ser preciso sobre o motivo: não porque três breakpoints seja um número grande, mas porque a mesma pessoa levou cada um deles do wireframe até o markup publicado, então não existe handoff em que a intenção responsiva pudesse ter se perdido.

Construído duas vezes: Vite, depois Next.js

A camada de landing pages foi construída primeiro em Vite com React Router, e depois migrada para Next.js em agosto de 2025. Os dois repositórios continuam públicos, e eu mantenho os dois de propósito — o par é o único registro honesto do que a migração de fato mudou. É também a coisa mais frequentemente dita errado sobre este projeto: o repositório antigo é Vite, não Next.js, e um scan de ferramentas que diga o contrário foi enganado por um pacote de tema cujo nome começa com as mesmas quatro letras.

O arquivo que provou uma afirmação justamente por não conter nada

Há um detalhe do arquivo de design aqui que importa mais do que parece. Ao longo dos projetos da agência eu havia propagado um arquivo base fortemente tokenizado, e a pergunta óbvia sobre uma afirmação dessas é se o arquivo segue a pessoa ou o empregador. Este projeto é o controle: é o único daquela fase cujo produto não fui eu que desenhei, e é o único arquivo sem o arquivo base dentro — um punhado de variáveis, nenhuma variável de cor, nenhuma das camadas de primitivos que todos os outros carregam. O arquivo segue a mim, não a agência. É uma ausência fazendo o trabalho de evidência.

O que isto não é

• Não é o produto. A aplicação, suas telas e seu modelo de papéis são trabalho de outra pessoa, e não vou reivindicar nada disso.
• Não são os aplicativos móveis. O produto foi publicado nas duas lojas sob o identificador da agência; aquelas fichas provam que o sistema entrou no ar, e são evidência sobre a agência, não sobre mim.
• Não é a discovery. O líder técnico conduziu a discovery em todos os projetos daquela fase e me entregou o quadro pronto.
• Não é o processo de entrega da agência. As quinze fases eram delas; eu executei uma etapa dentro delas.
• Não é uma alegação de conclusão a partir do cronograma. O recorte que está no arquivo de design é uma visão de meio de projeto e não pode ser citado como status.
• Não é evidência de que eu publiquei o sistema. Meu artefato publicado é a camada de landing pages — exatamente essa frase, e nenhuma mais curta.
• Não era meu cliente. A relação era da agência; eu entreguei como funcionário.

Durabilidade

Durante quase toda a vida deste projeto não existiu nenhum snapshot dele em lugar nenhum. Esse é um risco real para um portfólio construído sobre trabalho de cliente: o domínio vence, a hospedagem troca de mãos, e a evidência de um ano de trabalho seu desaparece sem que ninguém tenha feito nada de errado. Em agosto de 2026 eu submeti o site ao Wayback Machine e confirmei, lendo o índice do arquivo em vez de confiar no salvamento, que as seis rotas foram capturadas — incluindo as três páginas de público, que é o que faz a afirmação dos três públicos sobreviver ao domínio.

Evidência

As três páginas foram prototipadas em wireframe, desenhadas em 1280 e 375, construídas em Vite, migradas para Next.js e publicadas. Elas continuam no ar no domínio do projeto, que hoje sou eu quem hospeda — assumi a hospedagem em 2026, cerca de dez meses depois do fim do build, por razões que não têm nada a ver com o trabalho contratado; servir os arquivos hoje não diz nada sobre o que fui contratado para fazer na época. Em agosto de 2026 as seis rotas foram capturadas pelo Wayback Machine, então o trabalho não depende mais da sobrevivência do domínio. Não existe nenhuma métrica de desempenho para este projeto, nem para nenhum outro deste portfólio; é uma ausência confirmada, não uma ausência por falta de coleta.