Todo projeto tem uma história de origem banal. A do QuickGaragem começa com uma planilha Excel mal organizada, um celular antigo e um dono de loja que perdia venda toda semana porque o comprador não sabia se a peça que ele precisava estava em estoque.
O revendedor me chamou com uma reclamação simples: "Perco cliente toda hora porque não tenho como mostrar o que tenho." Sem site, sem Instagram com fotos atualizadas, sem nada. Quando alguém ligava perguntando sobre uma peça específica, ele precisava procurar na planilha, ligar de volta, e torcer pra que o comprador ainda estivesse interessado.
O diagnóstico antes de escrever uma linha
Antes de qualquer código, sentei com ele por uma hora e mapeei o fluxo real de como as vendas aconteciam. Esse passo salvou semanas de retrabalho.
O que descobri:
- A maioria dos contatos chegava por indicação boca a boca ou pelo número do WhatsApp que ele tinha no cartão
- O ciclo de compra era curto — o comprador queria a peça naquele dia, não numa semana
- O dono atualizava o estoque com frequência (às vezes várias vezes por dia) e precisava que o sistema fosse simples o suficiente pra ele mesmo gerenciar pelo celular
- Ele não queria pagar mensalidade de marketplace e perder comissão
Com esse mapa, o produto tomou forma natural: uma vitrine pública para os compradores encontrarem peças, com botão de WhatsApp direto em cada item, e um painel de administração privado que só ele acessa pelo celular.
Por que React + TypeScript + LocalStorage — sem backend
Aqui está a decisão técnica mais importante do projeto: zero servidor, zero banco de dados em nuvem.
A escolha pode parecer estranha. Mas pensa no contexto: o cliente é um revendedor individual, não uma empresa. Qualquer dependência de servidor significa custo mensal, risco de queda, e complexidade de manutenção. O localStorage do navegador armazena os dados localmente no dispositivo do administrador e a vitrine pública é servida como arquivo estático em qualquer CDN.
O TypeScript entrou pela segurança de tipo. Quando você tem um objeto Product com campos obrigatórios e o formulário do painel tenta salvar algo inválido, o compilador pega antes de chegar ao usuário. Em um projeto solo com prazo curto, isso vale mais do que qualquer teste unitário.
A regra que sigo: o sistema mais simples que resolve o problema real é o certo. Adicionar servidor onde não é necessário é débito técnico desde o dia 1.
A vitrine pública: foco em conversão, não em features
O comprador abre a vitrine, filtra por categoria (motor, suspensão, elétrica, etc.), vê a foto da peça, o preço e um botão verde de WhatsApp. Quando clica, o WhatsApp já abre com uma mensagem pré-preenchida identificando a peça. O vendedor recebe o lead qualificado — a pessoa já sabe o que quer.
Não há carrinho de compras. Não há checkout. Não há conta de usuário. Cada um desses elementos seria uma fricção a mais no caminho da conversão, e o modelo de negócio não precisava deles. A venda acontece no WhatsApp, como já acontecia antes — só que agora o lead chega informado.
O painel administrativo: simplicidade acima de tudo
O painel é protegido por senha simples (não há multi-fator, não há OAuth — é um painel pessoal de uso único). O dono cadastra uma nova peça preenchendo quatro campos: nome, categoria, preço e foto tirada pelo celular. Confirma e a peça aparece na vitrine em menos de um segundo.
Para editar ou marcar como vendida, ele toca no item e muda o status. A vitrine atualiza instantaneamente porque lê do mesmo localStorage.
Os números depois de 2 semanas no ar
+40
contatos de compradores
0%
comissão de marketplace
100%
gestão pelo celular
O dado que mais importou para o cliente não foi o número de acessos à vitrine — foi o volume de mensagens novas no WhatsApp. Em duas semanas, chegaram mais de 40 contatos de compradores que encontraram a peça pela vitrine. Antes, a média semanal era próxima de zero por canal digital.
A planilha foi aposentada. O dono opera tudo pelo celular. E nenhum centavo vai para intermediário.
O que eu faria diferente hoje
O localStorage funciona, mas tem um limite óbvio: os dados ficam presos no dispositivo do administrador. Se ele trocar de celular sem exportar, perde tudo. A evolução natural seria um backend leve — Workers + D1 no Cloudflare, por exemplo — com sincronização e backup automático. O custo ainda seria zero ou quase zero para o volume de dados envolvido.
Também adicionaria um sistema de notificação quando o estoque de um item fica baixo, e talvez uma página de "peças vendidas" para servir de histórico.
Mas o MVP entregue cumpriu o objetivo com folga. Às vezes a versão simples que funciona vale mais do que a versão perfeita que demora.
Tem um problema parecido?
Se você tem um negócio local com estoque manual, processo repetitivo ou qualquer fluxo que ainda depende de planilha ou papel, provavelmente dá pra resolver com menos complexidade do que você imagina. Me conta o que você está enfrentando.
Resolve um problema como esse
Respondo com proposta clara em até 24h — sem reunião prévia.