TSW.ai - Landing Page do The Student World AI em Nuxt 3

Resumo

• Entrega: landing page estática do The Student World AI (TSW.ai) com seções Hero, Features e CTA de Chat, além de um kit mínimo de UI para padronizar layout e botões.
• Como eu destravei: organizei a UI em seções e componentes reutilizáveis (layout + UI) para acelerar iterações de design/copy sem perder consistência.
• Efeito prático: página leve e direta, sem dependência de backend, focada em conversão (CTA) e preparada para deploy estático.

Em ~10 dias, fui responsável pela maior parte do front dessa landing (14 commits, ~82% do repositório no recorte), priorizando consistência visual e entrega rápida.

Contexto

• Produto e usuários: site de marketing para apresentar o TSW.ai e direcionar o usuário para a aplicação principal via CTA.
• Por que era crítico: precisava ser simples, estável e rápido de publicar/atualizar (copy e visual) para suportar aquisição.
• Decisão de arquitetura: escopo deliberadamente estático (SSR desabilitado) para reduzir complexidade operacional no curto prazo.

Principais desafios

• Transformar a intenção “landing page” em uma base organizada (seções, componentes e estilos) sem overengineering.
• Garantir consistência visual (tipografia, botões, espaçamentos) com Tailwind e estilos globais.
• Manter o site “stateless”: sem integrações de API, apenas links/CTAs e performance previsível.

O que eu fiz

• Página principal e seções: implementei a estrutura e as seções principais (Hero, Features e Chat/CTA).
• Componentização para iteração rápida: criei um conjunto de componentes reutilizáveis (UI e layout) para acelerar ajustes de copy/design sem regressão visual.
• Links e navegação externa: conectei CTAs e links do ecossistema (app principal, site institucional e redes sociais) de forma consistente.
• Configuração do projeto: Nuxt 3 + Tailwind + pnpm com build estático (SSR desativado).

Decisões & trade-offs

• Site estático (SSR off) > SSR: caminho mais simples para uma landing de aquisição (menos complexidade e deploy mais previsível).
  Trade-off: abre mão de benefícios de SSR (ex.: algumas estratégias avançadas de SEO/render), mas o escopo não exigia isso no momento.
• Componentes pequenos e reutilizáveis > página monolítica: separação em seções + kit mínimo de UI para manter velocidade e consistência.
  Trade-off: mais estrutura/arquivos, porém reduz retrabalho e facilita manutenção.
• Deploy via script (time) > pipeline CI: publicação estática em S3/CloudFront usando automação por script.
  Trade-off: funciona, mas depende de execução manual e credenciais locais.

Resultados

• Medido (engenharia): 14 commits (~82% do repositório no recorte), 7 dias ativos, entrega em ~10 dias (25/04/2025 → 05/05/2025).
• Proxy técnico (concreto):
  • Landing page com 3 seções principais (Hero, Features, Chat/CTA).
  • Kit mínimo de UI/layout para padronizar botões, modais e estrutura visual.
  • Integração por links/CTAs para app e canais do ecossistema.
• Operacional: base pronta para ajustes rápidos de copy/visual sem backend e com deploy estático em AWS (via processo do time).

Nota: não havia testes automatizados nem observabilidade configurada no recorte analisado.

O que eu faria diferente

• Adicionar testes mínimos de UI (componentes críticos como Header/Footer/Modal/CTA) para reduzir regressões visuais.
• Trocar deploy manual por CI (ex.: GitHub Actions) com preview/staging e invalidation automatizada.
• Observabilidade leve: eventos de CTA e tracking de erros para aprender com conversão real e detectar problemas cedo.