Em produção · Tatuapé, SP

Um mercadinho de 2005
com a prateleira inteira online.

O Bendito Coco abre coco na hora há vinte e um anos na Rua Tuiuti. O problema nunca foi o coco — era a fila do mercado grande às sete da noite. A loja foi para a internet com a prateleira inteira: 78 produtos, 10 seções e entrega própria em 26 bairros de São Paulo, num raio de 15 km da loja.

Meu papel: Engenharia, plataforma e dados
Design: Brave (@leorossigomes)
Modelo: E-commerce com entrega própria
Stack: Next.js App Router · Cloudflare

benditococo.com.br — está no ar, com preço e estoque de verdade.

O problema

Ser muito bom em uma coisa não fecha a compra do mês

A loja começou em 2005 como um ponto de coco verde gelado perto do metrô. Todo dia a mesma cena: gente voltando do trabalho, levando um coco, e perguntando se não tinha também um pão, um leite, alguma coisa pra não precisar entrar no mercado. A prateleira foi crescendo até virar mercadinho, e em 2022 chegou a prensa de leite de coco — a linha própria deixou de ser rótulo e passou a ser coisa feita nos fundos.

Levar isso para a internet tem uma dificuldade que loja de eletrônico não tem: frescor não se prova numa foto. Quem compra água de coco pela primeira vez num site novo não tem como saber se vai chegar gelada, se é de concentrado, se leva açúcar. A confiança é o produto — e ela precisava caber na tela.

Catálogo que não cabe em vitrine

Coco em cinco seções, mais hortifrúti, padaria, frios, mercearia e bebidas. Dez seções que precisam conviver sem virar hipermercado.

Frescor sem prova

“Selecionado” e “premium” não querem dizer nada. Sem origem, data e temperatura, é só adjetivo.

Entrega própria, janela curta

Quatro faixas por distância, de 45 minutos a duas horas, moto e bike, 26 bairros. Não há transportadora para culpar quando o coco chega quente.

Arquitetura

Catálogo na borda, carrinho no navegador

As páginas de produto e de categoria são renderizadas e servidas pela borda da Cloudflare — quem abre a loja recebe HTML pronto, não um esqueleto que só vira loja depois do JavaScript. O carrinho vive no próprio navegador, numa chave versionada do localStorage. Não existe sessão de servidor e não existe cookie para o carrinho: fechar a aba e voltar amanhã encontra a mesma compra.

A terceira camada não é um banco de dados. É câmara fria, prensa e bicicleta — e é ela que decide se a promessa da primeira camada é verdade.

Registros de decisão

Cinco escolhas e o que cada uma custou

Toda decisão de arquitetura tem consequência. Registrar só o lado bom é propaganda, não engenharia.

Checkout sem cadastro e sem senha

Situação: O comprador típico é vizinho, compra por impulso no fim da tarde e quer coco gelado em uma hora. Cada campo obrigatório entre o carrinho e o pedido é uma chance de desistir.
Decisão: Quatro passos — identificação, endereço, entrega, pagamento — pedindo nome, e-mail, celular e CPF opcional. Nenhuma conta, nenhuma senha, nenhuma confirmação por e-mail antes de comprar.
Custo: Sem conta não há histórico de pedidos nem endereço salvo do lado do servidor: quem compra de novo digita o endereço de novo. A troca foi consciente — a loja prefere perder a comodidade da segunda compra a perder a primeira.

Clube pago, com o preço de sócio visível antes de assinar

Situação: Programa de fidelidade de mercado costuma ser um cartão que ninguém acha na hora de pagar, ou uma assinatura que só compensa para quem calcula.
Decisão: O Clube Bendito custa R$ 19,90 por mês, e o preço de sócio já aparece no card do produto, ao lado do preço cheio, em 25 itens da loja — para quem não é sócio também. A loja publica a conta junto: 7,3% de desconto médio nesses itens, e R$ 273,00 de compra por mês para a mensalidade se pagar. Você vê a diferença, e o ponto de equilíbrio, antes de decidir se entra.
Custo: Dois preços visíveis na mesma tela é mais informação para o olho processar, e obriga a interface a explicar “no clube” em cada card — inclusive para quem nunca vai assinar, que passa a ver um preço melhor que não é o dele. Em troca, o desconto deixa de ser promessa e o cálculo de valer a pena fica do lado de fora do funil, onde o cliente consegue conferir.

Uma página inteira para o que a loja não vende

Situação: Frescor não se prova em foto, e todo site de alimento diz que é fresco. Adjetivo não diferencia ninguém.
Decisão: Publicar a lista dos 21 aditivos e práticas barrados, com número INS quando existe — o mesmo código que está na embalagem, para o cliente conferir sozinho. Junto vão as cinco origens com cidade e estado, o máximo de quatro dias entre colheita e câmara fria, e a faixa de 2 a 6 °C.
Custo: É uma trava permanente no sortimento: cada fornecedor novo agora precisa passar por uma lista pública, e afrouxar em silêncio deixou de ser possível. Foi o ponto do projeto — a restrição virou o argumento de venda.

Carrinho no navegador, não em sessão de servidor

Situação: Carrinho em sessão exige servidor com estado, cookie e uma identidade para pendurar a sessão — três coisas que uma loja de bairro não precisa manter para vender coco.
Decisão: O carrinho vive no localStorage numa chave versionada (bc.cart.v1), com a versão dentro do próprio dado. Quando o formato mudar, o código sabe o que está lendo em vez de estourar num objeto antigo.
Custo: O carrinho não atravessa dispositivos: o que você montou no celular não aparece no computador. Para compra de bairro resolvida em minutos, o custo é baixo — e em troca não existe estado de servidor para vazar, e o carrinho não depende de cookie.

Preço por unidade em tudo, e fornecedor com nome

Situação: Embalagem de 300 ml, 1 L e galão de 5 L do mesmo produto. Comparar de cabeça é trabalho do cliente, e nesse trabalho o mais barato aparente costuma ser o mais caro por litro.
Decisão: Quase todo card mostra o preço por litro ou por quilo — ficam de fora os vendidos na fruta, um por um, onde não há unidade a comparar. E a marca de quem produziu aparece acima do nome, inclusive quando não é a casa: Dona Zilda, Padaria Santa Clara, Sítio do Vale.
Custo: Dar palco a fornecedor de fora enfraquece a marca própria em alguns cards, e o preço por unidade às vezes mostra que o pacote grande não compensa. Os dois efeitos são o preço de ser conferível.

Estado atual

Onde a loja está

produtos no catálogo

seções, do coco à mercearia

bairros com entrega própria

aditivos e práticas barrados, com nome e número

Está tudo no ar: catálogo, busca, categorias, ofertas da semana com encarte, receitas que jogam os próprios ingredientes no carrinho, avaliação com compra verificada, aviso de reposição em item esgotado e checagem de CEP antes de montar a compra. O pagamento sai por Pix, cartão ou dinheiro na entrega.

O que não está aqui: números de venda, margem, custo de aquisição e o contrato. Loja de cliente em operação não publica o próprio caixa — e este case existe para mostrar decisão de engenharia, não faturamento de terceiro.

Transferência

O que dá para reaproveitar

Um catálogo de bairro não parece um SaaS B2B, mas os dois projetos resolveram o mesmo tipo de problema: colocar autoridade onde ela é verificável e tirar estado de onde ele não precisa existir.

Catálogo com variante, preço por unidade e estoque, servido pronto da borda — sem servidor de aplicação no caminho.
Carrinho versionado no cliente, que sobrevive a mudança de formato sem quebrar a compra de quem estava no meio dela.
Checkout de convidado em passos, com o resumo do pedido sempre visível ao lado.
Preço de sócio calculado e exibido junto do preço cheio, com a conta de valer a pena publicada ao lado da mensalidade.
Dados estruturados por produto, com marca, SKU e oferta — o que faz o item aparecer com preço no resultado de busca.
Uma página de padrões públicos: transformar a restrição do negócio em argumento verificável, em vez de adjetivo.

Próximo passo

Tem uma loja que o site não dá conta de mostrar?

Trinta minutos costumam bastar para eu dizer se é o meu tipo de problema — e, se não for, indicar quem resolve.

Pedir orçamento Agendar 30 minutos

← Ver os outros projetos

Um mercadinho de 2005com a prateleira inteira online.