Como eu construí o Cardápio no Zap: bastidores, decisões e erros

Construí o Cardápio no Zap com IA entre 8 e 11 de novembro de 2026, em fases pequenas: primeiro uma página de espera, depois cardápio, carrinho, envio no WhatsApp e painel do dono. No caminho, a IA errou, os testes deixaram passar defeitos que só o olho pegou, e o público mudou de lanchonete para qualquer negócio de comida.

O problema que eu escolhi

O Cardápio no Zap resolve uma cena comum no WhatsApp de qualquer lanchonete de bairro: o cliente pede por áudio, ou pede o cardápio em PDF e depois manda o pedido do jeito dele, e alguém do outro lado precisa ouvir, anotar e conferir tudo. No app, o cliente abre um link no celular, escolhe os itens, escreve "sem cebola" se quiser, e o pedido chega pronto e escrito no WhatsApp do estabelecimento. Sem comissão.

A frase que guiou o projeto inteiro foi esta: para donos de lanchonete de bairro, que perdem pedidos e tempo quando os clientes pedem por áudio ou pelo cardápio em PDF no WhatsApp, o app entrega o pedido pronto e organizado no WhatsApp da lanchonete. Tudo o que não servia a essa frase ficou para depois.

Escolhi esse problema por dois motivos. Ele está à vista de qualquer um: basta mandar mensagem para um negócio de comida em horário de pico e reparar na fila de áudios e na demora da resposta. E a solução cabe numa função só, que é transformar a escolha do cliente numa mensagem escrita e organizada. Um problema assim é ótimo para um primeiro app, porque dá para explicar em uma frase e testar em minutos.

Se você ainda está escolhendo a sua ideia, escrevi sobre isso em como validar uma ideia de app antes de construir.

A primeira coisa no ar foi uma página, não o app

Antes de existir cardápio, existia uma página de espera com o título "Pare de anotar pedido por áudio", três passos curtos e um botão "Quero entrar na lista" que abria o WhatsApp. Sem imagem de banco, sem número inventado, sem depoimento. A IA gerou o arquivo em cerca de 14 segundos.

Publicar foi bem mais lento. O painel da Cloudflare (o serviço que coloca o site no ar) travou na primeira tentativa e em mais duas rodadas. Esperei cada vez mais entre elas, até 10 minutos, e só na terceira rodada o site subiu. Da rodada que funcionou até o link no ar, foram uns 12 minutos. O painel travou até com o computador quase parado. Às vezes a ferramenta está lenta, e o certo é esperar antes de clicar de novo.

O que eu cortei, e por quê

Ficaram de fora pagamento online, entregador, estoque e cupom. Cada um desses itens, sozinho, aumentaria muito o projeto, e nenhum deles é necessário para o pedido chegar escrito no WhatsApp. A saída foi simples: a forma de pagamento e a taxa de entrega são combinadas na conversa do WhatsApp, que é onde o dono já conversa com o cliente.

Também cortei o login do cliente: ele só escreve o nome e, se for entrega, o endereço. A primeira versão atende um estabelecimento só, e só o dono entra no painel. Até a foto dos itens ficou para a última fase, porque o cardápio precisava funcionar sem ela primeiro.

Essa ideia de construir uma função só, e bem feita, é o assunto do meu e-book grátis "O app de uma função só". O Cardápio no Zap é o exemplo mais claro que eu tenho dela. Se quiser entender o conceito, comece por o que é um micro app.

Como foi trabalhar com a IA

Construí com o Claude Code, pedindo em português. Antes de qualquer código, a IA me fez 8 perguntas sobre o projeto (uma lanchonete ou várias, se tem foto, o que precisa aparecer na mensagem do WhatsApp) e só então escreveu dois documentos: um com o objetivo, as telas e as regras do app, e um plano dividido em fases pequenas. Cada fase terminava com algo que eu conseguia abrir e testar. Uma regra do documento se pagou várias vezes: nunca inventar dados. Por isso o cardápio de exemplo avisa, com todas as letras, que é um exemplo.

Também pedi que a IA anotasse tudo num diário: cada pedido, cada erro, quanto tempo levou. É dele que saem os números deste artigo. Eu entrava onde só o dono da conta pode entrar: fazer login nos serviços, criar o usuário do dono do painel, autorizar o GitHub e dizer "pode publicar". Ela não digitava senha nem publicava nada sem o meu ok.

Antes de avançar, criei um "botão de desfazer", que é guardar cada versão que funciona (o nome técnico disso é Git). Para testar, pedi de propósito uma mudança ruim: trocar o verde por rosa-choque e deixar os botões bem pequenos. O botão Adicionar ficou com 20 pixels de altura, impossível de acertar com o dedo. Pedi para voltar, e o app voltou igualzinho à última versão guardada, com o botão de novo em 49 pixels.

O que a IA errou

A parte mais útil do diário é a lista de erros. Nenhum foi plantado para a aula. Todos estavam no código que a IA escreveu.

Os testes passaram e os erros estavam lá

Na tela de finalizar, se o cliente escolhia "Entregar" e tentava enviar sem endereço, aparecia um aviso vermelho. Até aí, certo. Só que, depois de escrever o endereço, o aviso continuava na tela. O segundo erro: ao tocar em "Ver carrinho" depois de rolar o cardápio, a tela abria 338 pixels abaixo do começo, com o título "Seu carrinho" cortado lá em cima.

Nenhum dos dois impedia o pedido. Todos os testes do plano tinham passado. O que achou os dois foi olhar a tela como cliente. Cada correção foi pedida separada, uma de cada vez, e conferida na tela depois.

Quando o erro está no pedido

Pedi um botão "Dar opinião" e um botão "Premium" honesto, que só mostra "Ainda estamos criando o Premium. Quer ser avisado?" e registra o interesse, sem cobrança. A IA colocou os dois no cardápio, à vista do cliente da lanchonete. Só que quem paga pelo app e quem tem opinião sobre ele é o dono. O pedido não dizia quem ia usar o botão, e a IA escolheu errado. Movi os dois para o painel do dono, com um número de WhatsApp separado, o de quem fez o app.

Teve mais: o modelo de projeto não vinha configurado para esconder o arquivo das chaves de acesso, um pacote de publicação montado no Windows quebraria o site no ar, e o botão de enviar dava erro sem motivo se o cliente tocasse antes de o número do WhatsApp carregar. Os três foram pegos antes de publicar.

Juntei esses e outros tropeços em os erros mais comuns de quem cria o primeiro app com IA.

A falha de segurança que vinha de fábrica

O cardápio e o login ficam no Supabase, um serviço que guarda os dados e cuida das senhas. Ali, o cadastro público vem ligado. Na prática, qualquer pessoa com a chave pública do app (que fica visível no navegador, como deve ser) poderia criar uma conta, virar "usuário logado" e mudar o cardápio. Desliguei isso antes de publicar.

E a revisão de segurança mostrou que a regra inicial deixava qualquer pessoa logada alterar o cardápio. Mudou para só o dono, identificado pelo id dele. Nos testes, simulando um segundo usuário logado, a tentativa de editar um item e trocar o número do WhatsApp deu 0 linhas alteradas. Os campos ganharam limite de tamanho (um nome com 81 letras é recusado) e o número do WhatsApp passou a aceitar só números. O verificador do próprio Supabase foi de 3 avisos para 1.

Nada disso aparece na tela, e por isso eu insisto que segurança mínima entra antes de publicar.

O redesign: "está muito simples"

Com tudo funcionando, olhei o cardápio e achei sem graça. Era uma lista de texto com preço e botão. Pedi algo inspirador, usando o Impeccable, uma ferramenta de design que trabalha junto com a IA. Antes de mexer em qualquer coisa, a IA pesquisou exemplos de bons sites de restaurante. Dois achados guiaram o resto: foto grande e nítida de comida aparece em quase toda lista de bons sites de restaurante, e a única análise que ela encontrou sobre página de venda para donos de restaurante defende que foto real de comida convence mais o dono do que tela de sistema. Sobre categorias em botões e carrinho fixo, ela não achou dados. Ali, as escolhas foram de gosto.

O cardápio ganhou capa verde, categorias em botões que acompanham a rolagem, cartões com foto grande, preço em destaque, barra amarela de "Ver carrinho" e uma tela nova depois do envio, "Falta só um toque". O painel do dono ganhou o campo de foto opcional. As fotos são 7 imagens gratuitas do Unsplash. Nada de depoimento, logo de cliente ou promessa de renda.

O defeito que só apareceu depois de publicar

Publiquei e fui testar no link de verdade. Uma faixa verde cobria o topo do cartão branco no carrinho, no finalizar e na tela de sucesso. Os 8 testes automáticos passavam, porque eles conferem a conta e a mensagem do WhatsApp, e não a aparência. Corrigi e publiquei de novo.

Depois, na landing (a página de venda), eu mesmo vi dois detalhes: no computador, a primeira foto da seção "Como funciona" estava 7 pixels mais baixa que as outras, e em telas largas a foto do lanche invadia 15 pixels do título, escondendo a palavra "áudio". Nenhum teste pegaria isso. Antes, ainda no redesign, o PageSpeed (ferramenta do Google que mede a página) tinha apontado uma frase amarela com pouco contraste. Trocada a cor, a landing ficou com 99 de desempenho e 100 em acessibilidade, boas práticas e SEO, no celular.

De "lanchonete" para "estabelecimento"

O app nasceu falando com o dono de lanchonete. O botão da landing dizia "Quero para a minha lanchonete", e o cardápio avisava que o pedido ia "para o WhatsApp da lanchonete". Em 10 de novembro, troquei isso. O app passou a dizer "estabelecimento", o botão virou "Quero para o meu negócio", e a landing passou a listar lanchonete, pizzaria, hamburgueria, açaí, doceria e restaurante.

O nome Cardápio no Zap ficou. Mudou o público, e a troca mexeu em 7 arquivos do app e na landing inteira, porque "lanchonete" estava espalhada em avisos, mensagens de erro e na tela de sucesso.

O que pesou foi olhar para o que o app faz de fato. Montar um pedido escrito a partir de um cardápio serve do mesmo jeito para a pizzaria, para o açaí e para a doceria. A pizzaria recebe o mesmo áudio de três minutos que a lanchonete recebe. Deixar "lanchonete" em cada tela fechava a porta para negócios com exatamente o mesmo problema, sem ganhar nada em troca.

Outra questão de nome, menor: o endereço cardapio-no-zap.pages.dev já era da página de espera, que virou a landing de venda. O app foi para cardapio-no-zap-app.pages.dev.

O que o checkup de SEO mostrou

Em 11 de novembro, medi os dois sites de novo. A landing estava bem: 98 de desempenho e 100 no resto. O app, não: 75 de desempenho e 92 de SEO. Os motivos eram invisíveis para quem só usa o app:

• O app não tinha o arquivo que diz ao Google o que ele pode ler (o robots.txt). No lugar dele, o servidor devolvia a página inteira, e o Google lia aquilo como um arquivo com 29 erros.
• Qualquer endereço inventado, como /pagina-que-nao-existe, abria a página principal como se existisse. Para o Google, isso parece conteúdo repetido.
• A foto do primeiro lanche levava 6 segundos para aparecer no celular.
• O app e a landing tinham o mesmo título e disputavam o mesmo nome no Google.

Tudo isso entrou numa versão nova do app: página de erro de verdade, título e descrição que dizem que aquilo é um cardápio de exemplo, fotos menores no celular, um aviso ao Google para não indexar o painel do dono e um link discreto no rodapé, "Quero um cardápio assim", levando quem cai no exemplo para a página de venda.

Antes disso, a prévia do link no WhatsApp mostrava só texto, sem imagem. Uma imagem de prévia com a tela real do app resolveu.

As métricas que o app acompanha

O app registra poucos eventos no PostHog, uma ferramenta de métricas: cardápio aberto, item adicionado, pedido enviado e painel aberto. Escolhi esses quatro porque contam a história inteira de um pedido, do primeiro toque ao envio. Nome, endereço e telefone do cliente nunca são enviados para lá. A ferramenta sabe que alguém adicionou um item, mas não sabe quem.

Com esses eventos, o PostHog monta um funil: quantas pessoas abriram o cardápio, quantas colocaram algo no carrinho e quantas chegaram a enviar. Na landing, o painel mostra as visitas e os cliques em "Quero". Gosto dessa etapa porque é nela que o app deixa de ser só uma tela e passa a contar o que acontece com ele.

Um conselho para quando você montar o seu: desconfie de porcentagem com pouca gente. Com cinco pessoas, um funil de 20% não diz quase nada. Espere juntar visitas suficientes antes de tirar conclusões, e olhe o caminho das pessoas mais do que o número final.

O que eu levo desse projeto

Diga sempre quem vai usar cada coisa. O botão Premium foi parar na frente do cliente porque eu não disse que era para o dono. A IA preenche o que você deixa em aberto.

Teste passando não quer dizer tela certa. Os testes automáticos protegeram a conta e a mensagem o tempo todo. Mas a faixa verde, o aviso que não sumia, a foto 7 pixels mais baixa, tudo isso só apareceu porque alguém abriu a tela e olhou, de preferência no link publicado e no celular.

O que não aparece também conta. Com o cadastro público ligado ou sem o robots.txt, o app funcionava, e mesmo assim estava errado.

E cortar escopo cedo foi o que permitiu terminar. Sem pagamento, sem entregador, sem estoque, o app ficou pequeno o bastante para ser construído, quebrado, consertado e redesenhado em poucos dias.

Eu construí o Cardápio no Zap justamente para servir de exemplo do Método Micro App. O passo a passo completo, com os pedidos e as telas de cada etapa, está lá. O caminho em sete dias está resumido em como criar um app sem saber programar. E o app está no ar para você testar: o cardápio de exemplo fica em cardapio-no-zap-app.pages.dev e a página de venda em cardapio-no-zap.pages.dev.

Perguntas frequentes

O Cardápio no Zap é um aplicativo de celular?

Não. É um app para internet, não é aplicativo de celular: abre por um link, sem baixar nada na loja.

O cliente paga pelo app?

Não. Pagamento online ficou de fora de propósito. A forma de pagamento e a taxa de entrega são combinadas na conversa do WhatsApp.

Quanto tempo levou para construir?

Os registros vão de 8 a 11 de novembro de 2026. Muitas etapas levaram minutos para a IA, mas esses tempos não valem para quem está começando, que lê cada tela e testa com as próprias mãos.

O app guarda dados pessoais dos clientes nas métricas?

Não. A ferramenta de métricas registra só os passos (cardápio aberto, item adicionado, pedido enviado, painel aberto). Nome, endereço e telefone do cliente nunca são enviados para ela.