LP Blitzap — Landing Page

Landing page e checkout do Blitzap, plataforma de disparo em massa para WhatsApp com API Oficial da Meta, produto da EVOLX. Projeto Next.js (App Router) com animações GSAP/Motion, checkout persistido em PostgreSQL e tracking de conversões para GA4, Google Ads e Meta Pixel.

Site em produção: https://blitzap.com.br

Stack

Camada	Tecnologia
Framework	Next.js 16.2.1 (App Router, output standalone, Turbopack em dev)
UI	React 19.2.4 — sem Tailwind, CSS custom em app/globals.css
Animação	GSAP 3.14 + @gsap/react, motion (Framer) 12, @lottiefiles/dotlottie-react
Banco	PostgreSQL via pg 8.20
Linguagem	TypeScript 5
Container	Docker multi-stage node:22-alpine

Dimensões do projeto (re-verificadas em 2026-10-22): 72 arquivos .ts/.tsx em app/, components/, lib/ e hooks/, ~8,2 mil linhas, sendo 46 componentes em components/ (raiz + subpastas animations/, checkout/, contact/, features/, homologation/) e 7 hooks customizados em hooks/.

Seções da home (app/page.tsx)

A página inicial é composta, nesta ordem, por:

1. UrgencyBar — barra de urgência/oferta
2. Nav — navegação fixa com CTA
3. Hero — abertura com mockup de dashboard (HeroDashboardMockup)
4. Marquee — letreiro de logos/prova social
5. Problem — dor do público
6. Showcase — vitrine de funcionalidades (features: disparo, importação com IA, agendamento, painel, marca própria)
7. DashboardPreview — prévia do painel
8. Steps — passo a passo
9. Testimonials — depoimentos
10. Homologation — homologação WhatsApp API Oficial
11. Pricing — planos com abas por categoria
12. FAQ — perguntas frequentes (lib/faq-data.ts)
13. CTAFinal — chamada final
14. Footer — rodapé com links legais
15. WhatsAppCTA — botão flutuante de WhatsApp

Tudo envolvido por GSAPProvider (contexto GSAP) e SvgDefs (sprites SVG).

Páginas e rotas de API

Rota	Descrição
/	Home de vendas (seções acima)
/checkout	Formulário de pedido. Recebe query params ?plano=&categoria=&periodo= (períodos aceitos: trimestral [padrão], mensal, unico). Grava clientes + pedidos via POST /api/checkout. noindex
/contato	Formulário de contato (POST /api/contact) + canais de atendimento
/termos, /privacidade, /cookies, /lgpd	Páginas legais
POST /api/checkout	Valida dados, insere cliente e pedido no PostgreSQL
POST /api/contact	Apenas valida o formulário — ver Limitações conhecidas

Também fazem parte do app: app/sitemap.ts, app/robots.ts, app/manifest.ts e components/JsonLd.tsx (SEO/schema), além de metadata Open Graph/Twitter em app/layout.tsx.

Banco de dados

lib/db.ts cria as tabelas automaticamente na inicialização (CREATE TABLE IF NOT EXISTS):

• clientes — id, nome, email, telefone, created_at (índice por email)
• pedidos — id, cliente_id (FK), categoria, plano, periodo, preco, taxa_setup, created_at (índice por cliente_id)

Planos

Definidos em lib/plans.ts, com 5 categorias: saas, wl (marca própria), rv (revenda), sc (código fonte) e homo (homologação). Planos SaaS a partir de R$ 49,99/mês.

Integrações e tracking

• Google Tag Manager — container GTM-5984VVKH carregado em components/GoogleTagManager.tsx (script + noscript, afterInteractive). O Microsoft Clarity também é carregado no mesmo arquivo, com ID fixo no código.
• GA4 / Google Ads e Meta Pixel — lib/tracking.ts dispara eventos via dataLayer (GTM) + gtag + fbq simultaneamente: cta_click, select_plan (begin_checkout/InitiateCheckout), whatsapp_click (contact/Contact), homologation_click (Lead/Schedule), view_section, nav_cta_click, urgency_cta_click e trackGadsConversion para conversões do Google Ads.
• WhatsApp — CTAs apontam para wa.me/5534999999999 (número centralizado em WHATSAPP_NUMBER, lib/plans.ts).
• JSON-LD — dados estruturados via components/JsonLd.tsx.

Como rodar

Desenvolvimento

npm install
npm run dev        # http://localhost:3000 (Turbopack)

Requer uma instância PostgreSQL acessível e a variável DATABASE_URL configurada (as tabelas são criadas automaticamente na primeira gravação).

Outros scripts: npm run build, npm run start, npm run lint.

Docker

O Dockerfile é multi-stage (deps → builder → runner) sobre node:22-alpine, usa o output standalone do Next.js, roda como usuário não-root na porta 3000.

Build e execução diretos:

docker build -t lp-blitzap .
docker run -p 3000:3000 -e DATABASE_URL=... lp-blitzap

No ambiente local do monorepo Blitzap, o serviço lp é orquestrado por compose.yaml na raiz do workspace, com a porta mapeada para 127.0.0.1:3002 → 3000 e variáveis vindas de runtime/lp.local.env.

Variáveis de ambiente

A única variável lida em runtime pelo código é:

• DATABASE_URL — string de conexão PostgreSQL (usada em lib/db.ts)

Observação: os IDs de GTM e Clarity estão fixos no código-fonte (não são lidos de variáveis). Se forem externalizados no futuro, os nomes sugeridos seguem o padrão usado nos demais projetos do workspace: NEXT_PUBLIC_GTM_ID, NEXT_PUBLIC_CLARITY_ID, NEXT_PUBLIC_META_PIXEL_ID.

Este repositório não contém valores de segredos; arquivos .env* são ignorados pelo .gitignore.

Limitações conhecidas

• Formulário de contato sem integração real: POST /api/contact apenas valida os dados e imprime no console (console.log). A integração com webhook (ex.: n8n) ou serviço de e-mail está marcada como TODO na própria rota.
• IDs de GTM/Clarity hardcoded em components/GoogleTagManager.tsx, impedindo ambientes distintos (staging/prod) sem rebuild.
• O tipo Periodo em lib/plans.ts inclui anual, mas a API e o formulário de checkout aceitam apenas mensal, trimestral e unico.
• Não há testes automatizados nem CI configurados neste repositório.

Origem do repositório

Este repositório foi migrado do GitLab para o OmniGit em 22/10/2026:

• Origem: gitlab.com/evolx.mkt/lp-blitzap
• Destino: https://omnigit.dev/BLITZAP/lp-blitzap

O histórico completo de commits foi preservado na migração.

---

© EVOLX / Blitzap. Todos os direitos reservados.