O que acontece em cada um dos 7 dias para criar um app sem saber programar

Em 7 dias você vai de um problema real a um app no ar: um dia para achar o problema, um para provar que alguém quer, três para planejar e construir com IA, um para publicar e chamar as primeiras pessoas, e um para ler os sinais e decidir.

Antes do Dia 1: o que você precisa ter

Três coisas. Um computador, porque a construção é feita nele (depois de pronto, o app abre em qualquer celular). Uma assinatura de IA, que é quem vai escrever o código. E disposição para ouvir quem tem o problema, nem que seja por mensagem, sem sair de casa.

Você não precisa de uma ideia genial. Precisa de um problema chato e de uma semana. Neste artigo eu mostro o que acontece em cada um dos 7 dias do método que eu criei, o objetivo de cada dia e o que você tem nas mãos quando ele termina. Para ficar concreto, uso o Cardápio no Zap, o app que eu construí do zero para as aulas. O cliente de uma lanchonete, pizzaria ou restaurante escolhe no celular, e o pedido chega pronto no WhatsApp do estabelecimento. Ele está no ar, e você pode abrir no celular enquanto lê.

Se você ainda não sabe bem o que é um micro app, comece por este artigo. Aqui eu parto do princípio de que você quer fazer um.

Dia 1: encontre um problema real

O objetivo é sair da ideia que você imaginou e chegar num problema que pessoas reais já reclamam. A maioria das pessoas começa pela solução. Acorda com uma ideia, acha genial e sai construindo. No Dia 1 a gente faz o contrário e começa pela reclamação.

E reclamação está em todo lugar: no seu trabalho, na família, nos grupos de uma profissão, nas avaliações de uma estrela de sistemas que já existem, nos comentários de vídeos. Três desses lugares estão na internet. A pista mais forte é quando a pessoa já paga por alguma coisa e continua reclamando.

No Cardápio no Zap, a reclamação era fácil de ver. O cliente manda o pedido por áudio, a pessoa do balcão anota errado, o lanche sai errado. Para fugir disso, muita lanchonete entra nos grandes apps de delivery e passa a reclamar da comissão. Tem improviso, acontece todo dia e já existe dinheiro sendo gasto. Eu comparei cinco ideias da minha lista com critério, e o cardápio ganhou por dois motivos: tem lanchonete em todo bairro, então é fácil encontrar com quem falar, e elas já pagam para resolver o problema.

No fim do dia, você tem uma frase do problema. A minha ficou assim: "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 meu app entrega o pedido pronto e organizado no WhatsApp da lanchonete." Repara que ela não fala de inteligência artificial em nenhum momento. O dono da lanchonete não liga para a tecnologia. Ele liga para o pedido que sai errado.

Dia 2: prove que existe demanda

O objetivo é descobrir se alguém quer a sua solução antes de construir uma linha. É o dia que mais economiza tempo no método inteiro, e o que mais gente quer pular.

Começa olhando o que já existe. Muita gente encontra um concorrente e desiste. Eu vejo o contrário: concorrente é a prova de que o problema existe e tem gente pagando. O que você procura é a brecha. No Cardápio no Zap, a pesquisa mostrou três coisas. Os grandes apps de delivery levam muito pedido, mas cobram comissão em cada venda. Os cardápios digitais genéricos mostram o cardápio bonito, mas o pedido não chega organizado no WhatsApp. E o improviso mais comum, PDF e áudio, é de graça mas gera erro. Ninguém fazia uma coisa simples: cardápio por link, sem comissão, com o pedido pronto no WhatsApp da lanchonete pequena. Essa era a brecha.

Depois vêm as conversas com quem tem o problema, que podem ser todas por mensagem. A regra de ouro é perguntar sobre o que a pessoa já fez, e não sobre o que ela faria. "Você usaria o meu app?" sempre ganha um sim educado. "Quando foi a última vez que um pedido saiu errado?" traz a verdade. E vale mais um compromisso, como "me coloca na lista", do que dez elogios. No e-book grátis O app de uma função só, eu deixo três perguntas para usar numa conversa assim, até por mensagem.

Anote cada conversa logo depois que ela termina: o que a pessoa faz hoje, quanto isso custa em tempo ou dinheiro e a frase exata que ela usou para reclamar. Essa frase exata, com as palavras dela, muitas vezes vira o título da sua página de espera.

No fim do dia, você tem uma decisão escrita (seguir, ajustar ou trocar de ideia) e a sua primeira coisa no ar: uma página de espera simples, com um botão para entrar na lista. A do Cardápio tinha o título "Pare de anotar pedido por áudio". Essa página é um sinal que não depende de conversa: você posta o link nos grupos do seu público e conta quem pediu para entrar. Eu aprofundo esse dia em como validar uma ideia de app antes de construir.

Dia 3: planeje como engenheiro

O objetivo é segurar a vontade de sair construindo por mais um dia e decidir, antes do código, o que o app faz e o que ele não faz. É esse plano que faz os dias seguintes andarem rápido.

O primeiro passo é cortar. No Cardápio no Zap, ficaram de fora o pagamento online, o entregador, o estoque e o cupom. Cada corte desses vale semanas. O cliente paga como já paga hoje, combinando na conversa do WhatsApp. O app inteiro ficou com cinco telas: cardápio, carrinho e finalizar, para o cliente; entrar e painel, para o dono.

Depois a IA entra como entrevistadora. Antes de escrever qualquer código, ela me fez oito perguntas. O cliente precisa de login? (Não, ele só informa o nome.) O pedido é para buscar ou entregar? (Os dois.) Como ficam a forma de pagamento e a taxa de entrega? (Fora do app, combinadas no WhatsApp.) Com as respostas, ela escreveu o documento do projeto, que funciona como a memória do app: toda conversa nova com a IA começa lendo esse documento. E dividiu a construção em oito fases pequenas, cada uma terminando em algo que dá para ver e testar.

Quem confere é você. No meu documento, a IA colocou "envio no WhatsApp" como se fosse uma tela do app. Não é: o WhatsApp é para onde o pedido vai. Nesse caso não mudava nada na construção, então deixei. Mas é esse olhar que separa quem constrói de quem só pede.

No fim do dia, você tem o documento do projeto, o plano em fases e a primeira tela rodando no seu computador. No Cardápio, foram cinco lanches de exemplo com nome, descrição e preço, e um aviso na tela dizendo que eram de exemplo.

Dia 4: construa a função principal

O objetivo é fazer o app resolver o problema. No Cardápio no Zap, isso é o cliente montar o pedido e mandar pronto no WhatsApp, e o dono mudar o cardápio sozinho, com senha.

Antes de construir, eu criei um botão de desfazer: cada versão que funciona fica guardada, e dá para voltar a ela em segundos. Para mostrar isso nas aulas, eu pedi de propósito para a IA trocar todo o verde do app por rosa-choque e deixar os botões minúsculos. Ficou horrível e difícil de apertar no celular. Pedi para voltar, e o app ficou igual à última versão guardada, sem eu mexer em uma linha de código. É isso que dá coragem para mexer.

A construção vai uma fase por vez, e cada uma é testada com as mãos. No carrinho, eu adicionei um lanche de R$ 18,00 e um de R$ 29,50: total R$ 47,50. Aumentei o primeiro para três: R$ 83,50. Diminuí para dois: R$ 65,50. Faça a conta você mesmo. Não confie só no que a IA diz.

Só que todos os testes do plano passaram, e o app ainda tinha dois erros. O aviso de "escreva o endereço" continuava vermelho depois que o endereço já estava escrito. E o carrinho abria rolado, com o título cortado. Eu só vi porque usei o app como um cliente usaria. A correção veio com um pedido sem nenhuma palavra técnica, só descrevendo o que eu fiz, o que apareceu e o que eu esperava. Um erro por vez.

Ainda no Dia 4, o cardápio saiu do código e foi para um banco de dados, com o login do dono. E apareceu um risco que quase ninguém conta: o serviço de login vem com o cadastro aberto. Sem fechar isso, qualquer pessoa poderia criar uma conta e mudar o cardápio da lanchonete. Fechei logo depois de criar o dono.

Você termina o Dia 4 com a função principal funcionando no seu computador, os dados guardados de verdade, o login do dono e uma versão guardada para cada fase testada.

Dia 5: qualidade, segurança e métricas

O objetivo é transformar um app que funciona num app que dá para mostrar a gente de verdade. Bonito e fácil no celular, testado, seguro e medido.

No visual, o Cardápio ganhou foto grande em cada lanche, preço em destaque e uma barra amarela de "Ver carrinho" que não tem como não ver. Depois da mudança, os testes automáticos passaram, tudo verde, e mesmo assim tinha um defeito: uma faixa verde cobria o topo de três telas. Os testes conferem a conta e a mensagem. A aparência, só os seus olhos conferem.

Sobre os testes automáticos, uma coisa que eu faço sempre: depois que a IA criou os oito testes do Cardápio, eu pedi para ela estragar a conta do total de propósito. Dois testes acusaram na hora. Só então eu confiei neles. Um teste que sempre passa pode estar passando porque não confere nada.

Na segurança, a revisão achou um buraco real: qualquer pessoa logada podia alterar o cardápio, e não só o dono. Ficou só o dono. Os campos ganharam limite de tamanho, e um nome de lanche com 81 letras passou a ser recusado. O painel de segurança do banco foi de três avisos para um.

Nas métricas, entraram poucos eventos: cardápio aberto, item adicionado, pedido enviado, painel aberto e um toque no botão Premium. Nunca nome, endereço ou telefone de cliente. E aqui eu errei de um jeito instrutivo. Na primeira versão, os botões "Dar opinião" e "Premium" ficaram no cardápio, à vista do cliente da lanchonete. Só que quem pagaria pelo app é o dono. Mudei os dois para o painel do dono. Coloque os botões onde está quem paga.

O Dia 5 termina com um app com cara de produto, testes que você sabe que funcionam, o mínimo de segurança conferido e um medidor ligado.

Dia 6: publique e traga os primeiros usuários

O objetivo é sair do seu computador para um link que qualquer pessoa abre, e colocar esse link na mão das primeiras pessoas.

O app do Cardápio foi para cardapio-no-zap-app.pages.dev, num projeto separado da página de espera. Esse cuidado existe por um motivo: publicar o app por cima da página apagaria a página. Antes de publicar, apareceu um aviso de que o arquivo principal estava pesado, com 800 KB, o que deixaria o cardápio lento no celular. A parte que mede os eventos passou a carregar depois que a tela abre, e o arquivo caiu para 457 KB.

A página de espera virou uma página de venda honesta, com prints reais do app, como funciona e perguntas frequentes. Sem depoimento inventado e sem promessa de ganho. Na pergunta "Quanto custa?", está escrito que o valor ainda está sendo definido, porque era verdade. No PageSpeed, a ferramenta do Google que mede a velocidade, ela tirou 100 em desempenho, acessibilidade e boas práticas no celular, e 92 em SEO, só pela falta de um arquivo.

Publicar não é o fim. Depois de publicar, eu testei de novo, no link publicado: cardápio, carrinho, mensagem e painel pedindo login. E os primeiros usuários começam por quem já deu algum compromisso no Dia 2, e não por anúncio.

Resultado: o app e a página de venda no ar, testados no link, e as primeiras pessoas convidadas.

Dia 7: leia os sinais e decida

O objetivo é olhar os números com honestidade e decidir o próximo passo. A lição central do método inteiro está aqui: tráfego não é negócio.

São três sinais, do mais fraco para o mais forte. A pessoa usou de verdade a função principal, e não só abriu. Voltou outro dia sem você pedir. E pagou. "Eu pagaria" não conta. Para o terceiro sinal, o método usa uma pré-venda honesta, com um link de Pix, antes de colocar qualquer sistema de pagamento dentro do app.

Mil pessoas abrindo o seu app não significam nada se ninguém fizer a coisa principal.

Um cuidado prático antes de ler qualquer número: enquanto você constrói, quem mais abre o app é você. Marque os seus acessos como internos na ferramenta de métricas, ou desconte os seus testes na hora de contar. Senão você corre o risco de comemorar o próprio dedo.

O que sai do Dia 7 é uma decisão por escrito, com número e frase de quem usou: continuar, iterar ou descartar. Nenhuma das três é fracasso. Fracasso é não decidir e passar meses mexendo num app que ninguém usa. Se você descartar, perdeu uma semana, e não um ano.

O que os 7 dias não fazem

Sete dias não entregam um negócio pronto, e ninguém sério promete isso. Eles entregam um app no ar, um medidor ligado, os primeiros sinais de gente real e um jeito de testar se alguém paga. É pouco? Para quem nunca tirou uma ideia do papel, é a diferença entre "um dia eu faço" e saber, com dados, se vale continuar.

E o ciclo se repete. Se a decisão for iterar, você volta ao planejamento no mesmo app e muda uma coisa só, a que trava. Se for descartar, volta à sua lista de problemas e escolhe o próximo. O primeiro app é o mais lento. O segundo já sai com o caminho conhecido.

Nos meus três apps, isso aparece nas datas dos diários. O Cardápio no Zap foi construído entre 8 e 11 de novembro. O Orçamento no Zap e o Preço Certo saíram no mesmo dia, 11 de novembro, e o Preço Certo ficou pronto, com página de venda, em cerca de uma hora de relógio. Esses tempos são de quem já conhecia o caminho e não valem como meta para quem está começando. Mas mostram o que muda: o documento do projeto, o plano em fases e o jeito de testar já tinham formato, e cada app novo começou de um ponto mais adiante.

Neste artigo eu mostrei o que acontece e por quê. O passo a passo completo, com as 41 aulas, os pedidos prontos para a IA em cada etapa, o que fazer quando ela quebra o app e o código dos três apps de bônus, está no Método Micro App. E se você quer saber onde quem começa costuma tropeçar, eu juntei os tropeços em os erros mais comuns de quem cria o primeiro app com IA.

Perguntas frequentes

Preciso saber programar para seguir os 7 dias?

Não. A IA escreve o código a partir do que você pede em português. O seu trabalho é decidir o que construir, testar com as próprias mãos, descrever o que deu errado e conferir o que a IA fez.

São 7 dias corridos?

O método é dividido em 7 dias, e cada dia tem um resultado claro. O tempo de construção muda de pessoa para pessoa. Tem gente que faz um dia por semana, e tudo bem.

Preciso sair na rua para conversar com as pessoas?

Não. Dá para achar o problema em grupos, avaliações e comentários, e conversar por mensagem com quem tem o problema. Mas ouvir algumas pessoas reais, nem que seja por mensagem, faz parte.

O app que sai no Dia 6 é aplicativo de celular?

Não. É app para internet: abre por um link, no celular ou no computador, sem baixar nada na loja.