A Kosmobelle vende dermocosméticos de R$ 48 a R$ 605, tem catálogo com kits e protocolos, programa de distribuidores, rastreio de pedido, lista de desejos e checkout com cartão e Pix. Não roda em Shopify, não roda em VTEX, não paga percentual de faturamento para ninguém.

Roda em Next.js 16 e PostgreSQL 16, em servidor dedicado. Vou abrir a stack inteira, decisão por decisão, e explicar como faço isso para outras empresas.

• Stack: Next.js 16 (App Router + Turbopack), React 19, TypeScript, TailwindCSS 4 com shadcn/ui, Prisma 7, PostgreSQL 16, Auth.js.

• Infra: servidor dedicado Hetzner com Docker, Cloudflare na borda (DNS, SSL, proxy) e Cloudflare R2 para mídia. Deploy contínuo pelo Coolify Cloud.

• Integrações: e-Rede como gateway único para cartão e Pix, Melhor Envio para frete com contrato AG dos Correios, Resend para transacionais autenticados, n8n para automações internas.

• O que isso resolve: custo fixo baixo e previsível, controle total do dado, e liberdade para construir regra de negócio que plataforma pronta não suporta sem gambiarra.

• Para quem não vale a pena: loja simples, catálogo pequeno, operação padrão. Nesse caso plataforma pronta é mais barata e eu digo isso na primeira conversa.

Por que a Kosmobelle não cabia em plataforma pronta

Loja de dermocosmético parece simples por fora. Por dentro ela tem exigências que quebram template:

• Canal de distribuidores. Existe um público que compra no varejo e outro que compra como parceiro, com regras, cadastro e condições próprias. Isso é modelagem de dado, não é plugin.

• Produto com conteúdo técnico. Ativo, concentração, protocolo de uso, contraindicação. A ficha de produto precisa sustentar informação real, não três bullets genéricos.

• Frete com regra própria. Frete grátis por região a partir de um valor, com barra de progresso mostrando quanto falta para o cliente atingir a meta dentro do carrinho.

• Identidade visual sem concessão. Marca de alto padrão não sobrevive a tema comprado com CSS remendado por cima.

Plataforma pronta te entrega uma loja rápido. Depois te cobra caro, todo mês, para você conviver com as limitações dela.

A stack completa, e o motivo de cada escolha

Aplicação e interface

Next.js 16 com App Router e Turbopack, React 19 e TypeScript. O App Router permite decidir a estratégia de renderização por rota, e isso é o coração da performance de um e-commerce. Página institucional, ficha de produto e listagem podem ser pré-renderizadas. Carrinho, checkout e área do cliente precisam de dado fresco. Não é uma decisão global, é uma decisão por página.

TailwindCSS 4 com shadcn/ui. Prefiro componente que mora no meu repositório a biblioteca fechada que eu não consigo alterar. Com shadcn o código do componente é meu, então customização de marca não vira briga com a biblioteca.

Auth.js. Autenticação de cliente, de administrador e de parceiro no mesmo sistema, com sessões e níveis distintos. Autenticação é a área onde improvisar sai mais caro, então uso solução consolidada.

Dados

Prisma 7 com PostgreSQL 16, em servidor dedicado Hetzner. O Postgres não fica em serviço gerenciado caro nem exposto na internet: a porta 5432 está fechada na borda pelo firewall. Acesso só de dentro da rede da aplicação.

Backup diário automático para o Cloudflare R2, com uma rotina que valida diariamente a consistência entre banco e objeto armazenado. Backup que ninguém testa não é backup, é esperança. Essa validação diária é a diferença entre achar que você tem cópia e saber que tem.

Borda, mídia e domínios

Cloudflare cuidando de DNS, SSL e proxy nas zonas .com e .com.br. Isso entrega TLS, cache de estático e uma camada de proteção antes do tráfego chegar ao servidor de origem.

Cloudflare R2 para a mídia, servida por subdomínio próprio. O upload força conversão para WebP em qualquer entrada, o que impede alguém de subir um JPEG de 4 MB e destruir o carregamento da vitrine. E existe lixeira de 30 dias: imagem excluída por engano volta, o que evita o pânico clássico de "apaguei a foto do produto campeão de vendas".

Deploy e ambientes

Coolify Cloud fazendo CI/CD sobre containers Docker. Push na branch main publica em staging, push na production publica em produção. Nada de deploy manual por FTP, nada de alguém editando arquivo no servidor às 23h.

Migrations aditivas rodam automaticamente no entrypoint do container. Migrations destrutivas, como remover coluna ou tabela, são executadas manualmente antes, com backup na mão. Essa separação evita o pior acidente possível: um deploy de rotina apagando dado de produção.

Integrações

• e-Rede como gateway único, cobrindo cartão e Pix. Um gateway em vez de dois reduz superfície de erro, simplifica conciliação e concentra o suporte em um contrato só.

• Melhor Envio para cotação e etiqueta, com SEDEX e PAC via contrato AG dos Correios. Cotação em tempo real no carrinho, etiqueta gerada a partir do pedido.

• Resend para e-mail transacional, com o domínio autenticado por SPF, DKIM e DMARC. Sem essa tríade configurada, confirmação de pedido cai em spam e o cliente abre chamado achando que a compra não passou.

• n8n em subdomínio próprio para automações internas. É onde ficam as rotinas que não precisam morar dentro da aplicação.

As decisões técnicas que o cliente final sente

Rápido sem mostrar preço errado

O erro mais comum em loja feita com framework moderno é escolher um extremo. Ou tudo estático, e aí o cliente vê estoque e preço desatualizados. Ou tudo dinâmico, e aí cada visita bate no banco e a loja fica lenta.

A abordagem correta é cirúrgica: pré-renderizar o que é estável, marcar como dinâmico apenas o que precisa consultar o banco naquele instante, e revalidar o resto por evento. Preço e estoque atualizados onde importa, resposta imediata em todo o resto.

Checkout que não cobra duas vezes

Essa é a parte que separa loja profissional de projeto de estudante. Três pontos que implementei:

1. Idempotência. Cliente com internet ruim clica duas vezes em "pagar". Sem chave de idempotência, isso vira duas cobranças, um chargeback e uma avaliação ruim. Com ela, a segunda tentativa reconhece a primeira e devolve o mesmo resultado.

2. Mensagem escalonada na recusa. Cartão negado não pode retornar "erro ao processar". A resposta muda conforme o motivo e conforme a tentativa, orientando o cliente a corrigir dado, tentar outro cartão ou pagar por Pix. Recuperação de checkout recusado é receita que a maioria das lojas simplesmente joga fora.

3. CPF ou CNPJ e telefone obrigatórios. Não é burocracia: sem esses campos a etiqueta de envio não sai. Melhor exigir no checkout do que descobrir na hora de despachar e ter que caçar o cliente no WhatsApp.

Plataforma pronta contra plataforma própria: a conta real

Vou ser honesto, porque post de desenvolvedor sobre esse tema costuma ser propaganda disfarçada.

Plataforma pronta ganha quando: você está validando o negócio, o catálogo é pequeno, a operação é padrão, não existe canal B2B nem regra de precificação por perfil, e o time não tem ninguém técnico. Nesses casos, pagar mensalidade é mais barato que pagar desenvolvimento.

Plataforma própria ganha quando: o faturamento cresceu a ponto de o percentual da plataforma virar um salário por mês, existe regra de negócio que o template não suporta, a marca precisa de identidade que tema pronto não entrega, ou você precisa do dado do cliente dentro de casa, não dentro do banco de dados de terceiros.

O ponto de virada não é técnico, é aritmético: some mensalidade, comissão sobre venda, custo de aplicativos extras e o custo de conviver com o que não dá para fazer. Quando essa soma anual passa a ser comparável ao custo de construir, a conta virou. Eu acompanho esse tipo de comparação de custo e margem no Controle, justamente porque decisão de infraestrutura sem número é opinião.

Quando eu digo para o cliente não fazer

Já recomendei plataforma pronta para gente que me procurou querendo sistema próprio. Se a loja fatura pouco, tem dez produtos e nenhuma regra especial, construir do zero é queimar dinheiro. Prefiro perder o projeto a entregar uma solução superdimensionada que vira peso morto seis meses depois.

Como eu construo isso para outras empresas

Fase 0: diagnóstico

Antes de qualquer linha de código, eu levanto catálogo, variações, regras de preço, canais de venda, fluxo fiscal, logística e integrações obrigatórias. É aqui que aparecem os detalhes que quebram cronograma: contrato de frete, tipo de nota, regime tributário, particularidade de embalagem.

Fase 1: fundação

Modelagem de dados, design system com a identidade da marca, catálogo, carrinho, checkout, gateway, frete, e-mail transacional, painel administrativo e infraestrutura completa com domínio, SSL, backup e deploy contínuo. É a fase que coloca a loja no ar vendendo de verdade.

Fase 2: operação

Emissão fiscal, relatórios, gestão de pedidos, cupons, integrações internas, automações. É o que transforma um site que vende em um sistema que a equipe consegue tocar sem depender de desenvolvedor todo dia.

Fase 3: crescimento

Canal de distribuidores ou B2B, tabelas de preço por perfil, programa de fidelidade, SEO técnico, otimização de conversão. Só faz sentido depois que a base está estável.

O que a empresa recebe no fim

• O código. Repositório em nome da empresa, com histórico.

• A infraestrutura no nome dela. Servidor, domínio, contas de gateway, e-mail e armazenamento. Cliente refém de fornecedor é modelo de negócio ruim, e eu não trabalho assim.

• Documentação de operação. Como publicar, como restaurar backup, como rodar migration, onde estão as chaves.

O que ter pronto antes de me chamar

1. Catálogo organizado em planilha: nome, descrição, preço, peso, dimensões, variações, código interno. Peso e dimensão são obrigatórios para cotar frete, e é o que mais atrasa projeto.

2. Fotos em alta resolução e padrão visual definido. Foto ruim derruba conversão mais que qualquer detalhe de código.

3. Definição fiscal: regime tributário, tipo de nota, quem emite, se há contador envolvido.

4. Conta de gateway e contrato de frete encaminhados. São processos com prazo próprio, e começar cedo evita a loja ficar pronta esperando aprovação de terceiro.

5. Quem vai operar a loja no dia a dia. Sistema sem dono na empresa morre, por melhor que seja.

A virada

Não existe mágica nessa stack. Existe decisão consciente em cada camada, e a soma dessas decisões é o que produz uma loja rápida, barata de manter e que faz exatamente o que o negócio precisa, não o que o template permite.

Se você tem uma operação que já vende e está pagando percentual sobre faturamento para conviver com limitação, faça uma conta simples esta semana: quanto você pagou de mensalidade e comissão de plataforma nos últimos doze meses. Se o número te incomodar, o problema deixou de ser técnico e virou financeiro, e aí vale conversar.

Publico por aqui no blog as decisões técnicas dos projetos que entrego, com stack aberta e sem promessa mágica. E se quiser ver o resultado funcionando antes de qualquer conversa, navegue a loja da Kosmobelle, adicione um produto ao carrinho e repare no tempo de resposta.

Perguntas frequentes

Quanto custa fazer um e-commerce próprio em vez de usar plataforma pronta?

Depende inteiramente do escopo, e desconfie de quem responde com número fechado sem ver catálogo, regras de preço e integrações. O que dá para afirmar é o outro lado da conta: a infraestrutura de uma loja como essa, com servidor dedicado, armazenamento e borda, custa uma fração do que se paga em mensalidade mais comissão sobre faturamento em plataforma de assinatura.

Por que Next.js e não WordPress com WooCommerce?

Já trabalhei muitos anos com PHP e WordPress, então falo com conhecimento dos dois lados. WooCommerce resolve bem loja simples. O problema aparece quando a operação cresce: dependência de dezenas de plugins de terceiros, superfície de ataque grande, performance que exige camada de cache sobre camada de cache e customização que sempre esbarra no tema. Com Next.js e Postgres, a regra de negócio é código no meu repositório, versionado e testável.

A loja fica presa em você depois de pronta?

Não. Repositório, servidor, domínio e contas de gateway ficam em nome da empresa, com documentação de operação. Suporte contínuo é opcional, não é armadilha contratual.

Quanto tempo leva para colocar uma loja assim no ar?

A fundação, com catálogo, checkout, frete, e-mail e painel, é a fase mais longa e depende principalmente da velocidade do cliente em entregar catálogo, fotos e aprovações de gateway e contrato de frete. A parte técnica raramente é o gargalo. O gargalo costuma ser dado faltando.

Dá para migrar de Shopify, Nuvemshop ou VTEX sem perder SEO?

Dá, mas exige planejamento: mapa completo de URLs antigas, redirecionamentos 301 um a um, preservação da estrutura de dados de produto e monitoramento de indexação nas semanas seguintes. Migração feita sem esse mapa é a forma mais rápida de perder tráfego orgânico que levou anos para construir.

Preciso de servidor dedicado ou dá para usar hospedagem compartilhada?

Para uma aplicação desse tipo, servidor dedicado ou VPS é requisito, não luxo. Você precisa de Docker, de banco isolado com porta fechada na borda, de rotina de backup e de deploy contínuo. Hospedagem compartilhada não entrega isso, e o custo de um servidor adequado é menor do que a maioria imagina.