Surfers Paradise · E-commerce e operação de loja · 2026
Não era apenas uma loja online. Era preciso construir toda a operação de e-commerce.
E-commerce completo para uma loja de surf com 20 anos de mercado no Brasil: catálogo, checkout com PIX, boleto e cartão, logística e painel de gestão.
- E-commerce
- Pagamentos
- Logística
- Cliente
- Surfers Paradise, Brasil
- Estado
- Em produção.
- 3
- meios de pagamento: PIX, boleto e cartão parcelado
- 17
- modelos de dados, ~60 rotas de API
- 9
- scopes Melhor Envio: cotação, etiquetas, tracking
Homepage — banners geridos no painel, marcas em destaque, produtos com preço PIX e parcelas.
Contexto
Uma loja física de surf com duas décadas de história queria vender online com a mesma profundidade de catálogo das grandes lojas brasileiras do setor: pranchas, wetsuits, quilhas, acessórios, dezenas de marcas.
Já tinha construído o e-commerce da Elite Surfing em React/Vite + Express. Este projeto foi a oportunidade de migrar essa arquitetura para um monorepo Next.js e resolver de raiz o que tinha aprendido.
O problema
Produtos de surf não são "um produto com variantes": uma prancha 5'10 e a mesma prancha 6'3 têm preço, stock, SKU e fotos diferentes. O modelo de dados tinha de refletir isso sem transformar o catálogo num pesadelo de gestão.
O mercado brasileiro exige PIX, boleto e cartão parcelado, cálculo de frete por CEP com várias transportadoras, nota fiscal, e proteção contra fraude — tudo com o cliente a sair se o checkout demorar.
O meu papel
Único developer: arquitetura, modelo de dados, integrações de pagamento e logística, painel de administração, SEO e catalogação inicial com a cliente.
Restrições
- Catálogo profundo com variantes reais (tamanho, cor) que têm SKU, stock, preço e fotos próprios.
- Mercado brasileiro: PIX, boleto, parcelamento, frete por CEP com várias transportadoras, nota fiscal.
- Fraude: uma loja nova é alvo imediato de cartões testados e pedidos falsos.
- A equipa da loja tinha de operar o painel sem apoio técnico.
Solução
Monorepo Next.js 16 com 17 modelos Mongoose e cerca de 60 rotas de API. Sistema de "família de produtos": cada tamanho ou cor é um produto independente agrupado por família, com uma variante principal nas listagens e botões de troca na página do produto.
Checkout com revalidação de preços e stock no servidor, cupões validados server-side, pagamentos via Mercado Pago (Card Payment Brick, PIX com QR dinâmico, boleto) com webhook assinado, e cron para cancelar pedidos expirados.
O que foi construído
- Painel de administração: categorias hierárquicas (3 níveis), marcas, produtos com imagens múltiplas e SEO, banners por posição, cupões, fornecedores, pedidos.
- Melhor Envio com todos os 9 scopes: cotação por CEP, carteira, geração e impressão de etiquetas.
- Importação de NF-e de fornecedores (XML) para entrada de stock, item a item.
- Ponto de venda (POS) para vendas na loja física, fecho de caixa e romaneios.
- Anti-fraude: bloqueio silencioso, validação de CPF, deteção de texto aleatório, emails descartáveis, verificação de velocidade.
- Login com Google e email/password (OTP), recuperação de password, retoma de pagamentos PIX/boleto pendentes.
- Blog, newsletter LGPD com cupões, wishlist, reviews, SEO com sitemap gerado a partir do MongoDB.
Decisões-chave
Variantes como produtos independentes
Em vez de opções dentro de um produto, cada tamanho/cor é um documento próprio com productFamily, variantType e isMainVariant. Custa mais no cadastro, mas o stock, o SKU e as fotos ficam certos — que é o que interessa a quem embala.
Mercado Pago em vez de Pagar.me
O checkout foi construído em Pagar.me V5 e migrado para Mercado Pago quando as condições comerciais e a estabilidade do PIX justificaram. A abstração de pagamentos permitiu trocar sem tocar no resto do checkout.
Resultado
Loja em produção com catálogo, pagamentos, frete e nota fiscal a funcionar de ponta a ponta, e um painel que a equipa da loja opera sem apoio técnico.
A arquitetura tornou-se a base de dois projetos seguintes para outras marcas do setor.
O que mudaria
A abstração de pagamentos pagou-se sozinha na migração de Pagar.me para Mercado Pago. Numa próxima loja faria o mesmo para o frete desde o primeiro dia.
Variantes como produtos independentes foi a decisão certa para quem embala; para quem cadastra, precisa de mais automação no painel — clonar família, edição em massa.
Stack
Next.js 16 · TypeScript · MongoDB · Mongoose · NextAuth v5 · Mercado Pago · Melhor Envio · Resend · Cloudinary · Zod · Vercel
