Surfers Paradise · E-commerce and store operations · 2026
Building a complete commerce operation, not just an online store.
Complete e-commerce for a surf shop with 20 years in the Brazilian market: catalog, checkout with PIX, boleto and card, logistics and admin panel.
- E-commerce
- Payments
- Logistics
- Client
- Surfers Paradise, Brazil
- Status
- In production.
- 3
- payment methods: PIX, boleto and installment cards
- 17
- data models, ~60 API routes
- 9
- Melhor Envio scopes: quotes, labels, tracking
Homepage — admin-managed banners, featured brands, products with PIX price and installments.
Context
A physical surf shop with two decades of history wanted to sell online with the same catalog depth as the big Brazilian stores in the sector: boards, wetsuits, fins, accessories, dozens of brands.
I had already built the Elite Surfing e-commerce in React/Vite + Express. This project was the chance to migrate that architecture to a Next.js monorepo and fix at the root what I had learned.
The problem
Surf products are not "one product with variants": a 5'10 board and the same board in 6'3 have different price, stock, SKU and photos. The data model had to reflect that without turning the catalog into a management nightmare.
The Brazilian market requires PIX, boleto and installment cards, shipping by postal code across several carriers, fiscal invoices, and fraud protection — all while the customer leaves if checkout is slow.
My role
Sole developer: architecture, data model, payment and logistics integrations, admin panel, SEO and initial cataloging with the client.
Constraints
- Deep catalog with real variants (size, colour) that have their own SKU, stock, price and photos.
- Brazilian market: PIX, boleto, installments, shipping by postal code across several carriers, fiscal invoices.
- Fraud: a new store is an immediate target for card testing and fake orders.
- The shop team had to operate the admin panel without technical support.
Solution
Next.js 16 monorepo with 17 Mongoose models and around 60 API routes. "Product family" system: each size or colour is an independent product grouped by family, with a main variant in listings and switch buttons on the product page.
Checkout with server-side price and stock revalidation, server-validated coupons, payments via Mercado Pago (Card Payment Brick, dynamic-QR PIX, boleto) with signed webhook, and a cron to cancel expired orders.
What was built
- Admin panel: hierarchical categories (3 levels), brands, products with multiple images and SEO, banners by position, coupons, suppliers, orders.
- Melhor Envio with all 9 scopes: quotes by postal code, wallet, label generation and printing.
- Supplier NF-e (XML) import for stock intake, item by item.
- Point of sale (POS) for in-store sales, cash closing and packing lists.
- Anti-fraud: silent block, CPF validation, gibberish detection, disposable emails, velocity checks.
- Google and email/password login (OTP), password recovery, resume of pending PIX/boleto payments.
- Blog, LGPD-compliant newsletter with coupons, wishlist, reviews, SEO with a sitemap generated from MongoDB.
Key decisions
Variants as independent products
Instead of options inside a product, each size/colour is its own document with productFamily, variantType and isMainVariant. It costs more at data entry, but stock, SKU and photos stay correct — which is what matters to the person packing.
Mercado Pago instead of Pagar.me
Checkout was built on Pagar.me V5 and migrated to Mercado Pago when commercial terms and PIX stability justified it. The payments abstraction allowed the swap without touching the rest of checkout.
Outcome
Store in production with catalog, payments, shipping and fiscal invoices working end to end, and a panel the shop team operates without technical support.
The architecture became the base for two subsequent projects for other brands in the sector.
What I would change
The payments abstraction paid for itself during the Pagar.me → Mercado Pago migration. In the next store I would do the same for shipping from day one.
Variants as independent products was right for the person packing; for the person cataloguing, it needs more automation in the admin — clone family, bulk edit.
Stack
Next.js 16 · TypeScript · MongoDB · Mongoose · NextAuth v5 · Mercado Pago · Melhor Envio · Resend · Cloudinary · Zod · Vercel
