Como fazemos um app ao vivo em palestra (o roteiro da demo de 15 minutos)

A demo de app ao vivo em palestra segue um roteiro fixo de 15 minutos: 2 minutos pra colher a dor real da plateia, 3 minutos pra montar um prompt inicial estruturado, 8 minutos de construção narrada em tempo real e 2 minutos pra fazer o deploy e mostrar o QR code funcionando na tela. O tema não é combinado antes. É esse detalhe que transforma a demo em prova, não em teatro.

Como funciona o roteiro de uma demo de app ao vivo em palestra?

O roteiro tem 15 minutos cravados, divididos em 4 blocos com tempo fechado cada um. Não é flexível: se um bloco estoura, o próximo encolhe, porque o relógio da palestra não espera.

• Bloco 1 (2 min): colher a dor real da plateia, ao vivo, sem sugestão pré-combinada.
• Bloco 2 (3 min): transformar a dor escolhida num prompt estruturado, em voz alta, pra plateia ver o raciocínio.
• Bloco 3 (8 min): construir o app narrando cada passo que a IA está executando.
• Bloco 4 (2 min): publicar o app e mostrar o QR code na tela pra plateia acessar no próprio celular.

A soma dá 15 minutos porque é o que cabe dentro de uma palestra de 60-90 minutos sem engolir o resto do conteúdo. Não acho que dá pra cortar os dois primeiros blocos. Porque colher a dor e estruturar o prompt é o que separa demo de encenação, sem isso vira mágica de palco.

Como a gente colhe a dor da plateia nos primeiros 2 minutos?

A gente colhe a dor perguntando direto: “qual processo aqui dentro ainda é feito no papel, no WhatsApp bagunçado ou numa planilha que só uma pessoa entende?” A plateia grita respostas, e uma é escolhida na hora, sem curadoria prévia.

Isso é proposital. Se o tema fosse combinado com a organização do evento antes, a demo perderia a força de prova, e a plateia sabe reconhecer quando algo foi ensaiado.

Exemplo hipotético: numa palestra pra uma rede de salões de beleza, alguém grita “fila de espera da manicure, hoje é papel na recepção”, e esse vira o tema. Em outro evento, com uma distribuidora, pode sair “controle de troca de mercadoria com fornecedor”. O critério é simples: precisa ser um problema que cabe numa frase, não um sistema inteiro.

Como monta o prompt inicial estruturado em 3 minutos?

O prompt inicial segue uma estrutura fixa de 4 partes, faladas em voz alta pra plateia acompanhar o raciocínio: quem usa o app, qual é o problema, qual dado entra e qual resultado sai no final.

No exemplo do salão de beleza: “quero um app onde a recepcionista cadastra o nome do cliente, o serviço (corte, manicure, escova) e o sistema mostra a fila em tempo real, com o tempo médio de espera calculado”. É a estrutura completa, dita em menos de um minuto.

O que garante o resultado não é a ferramenta, é a clareza da descrição. Isso já apareceu aqui quando falei de Claude Code: a parte técnica é do agente, descrever o processo com precisão é sua. Numa demo de palco isso fica mais evidente ainda, porque a plateia vê o prompt inteiro na tela, sem edição.

Como narrar a construção do app pra quem não é técnico entender (8 minutos)?

A narração funciona traduzindo em tempo real o que a IA está fazendo, enquanto o código aparece na tela: “agora ela está criando a tabela que guarda o nome de cada cliente que chega”, “aqui ela está montando a tela que a recepcionista vai ver”. Sem jargão técnico solto sem explicação.

A tela fica dividida em duas: de um lado o terminal rodando (Claude Code ou Lovable, dependendo do app), do outro a pré-visualização do que está sendo construído. Quem palestra comenta cada decisão como se explicasse pra um funcionário novo.

Quando algo dá errado nesse bloco, a reação importa mais que o erro em si. Um erro de sintaxe que a própria IA corrige sozinha, mostrado ao vivo, reforça a prova em vez de quebrar ela. Fingir que erro não existe é que soa falso.

Como fecha a demo com deploy e QR code na tela (2 minutos)?

O bloco final publica o app numa URL real (via Vercel ou o botão de publish do Lovable) e converte esse link num QR code exibido na tela, pra qualquer pessoa da plateia escanear e abrir o app no próprio celular, ainda dentro da palestra.

Esse é o momento de maior impacto do roteiro. Não é o palestrante dizendo “criamos um sistema completo em poucos minutos”. São, tipicamente, algo entre 200 e 300 pessoas, dependendo do porte do evento, com o celular na mão testando o app que acabaram de ver nascer.

O ponto crítico é o link já estar ativo e publicado antes de mostrar o QR code na tela, não durante. Ferramenta simples de gerar QR code resolve o resto.

Por que a demo ao vivo funciona melhor do que passar slide bonito?

A demo ao vivo funciona porque troca promessa por prova, na frente de quem vai decidir se aplica aquilo ou não. Slide bonito mostra um resultado editado. App nascendo na tela mostra o processo inteiro, com risco real de dar errado.

Já expliquei em outro texto que demo ao vivo custa mais caro que slide justamente por isso: quem apresenta assume o risco de travar na frente de centenas de pessoas, e treina mais antes pra reduzir esse risco.

Sendo bem sincero: boa parte do ceticismo com IA em empresa vem de já ter visto demonstração maquiada, com resultado pronto de antemão e narrado como se tivesse acontecido ali. Quando a plateia vê o app não existir e, 15 minutos depois, existir e funcionar no celular dela, o ceticismo cai de um jeito que slide nenhum replica.

O que pode dar errado numa demo ao vivo (e como a gente contorna?)

O erro mais comum não é a IA travar, é a plateia escolher um problema grande demais pra caber em 8 minutos. Isso se contorna já na pergunta do bloco 1, pedindo um processo específico (“uma tela, um formulário, uma lista”), não um sistema inteiro (“todo o financeiro da empresa”).

Outros riscos reais e como a gente reduz cada um:

• Internet cair no meio da construção. Testar a rede do local antes e levar um ponto de internet móvel de backup, sempre.
• A IA travar num detalhe técnico. Deixar uns 30-60 segundos de folga no bloco 3 pra corrigir sem pressão visível.
• O prompt sair confuso por nervosismo. Praticar a estrutura de 4 partes com temas hipotéticos diferentes antes do evento.
• A plateia pedir algo impossível em 8 minutos (login, pagamento, integração com sistema legado). Explicar na hora que aquilo entra numa segunda fase, e focar no núcleo que dá pra provar ali.

Nenhum risco é eliminado 100%. O que muda é que eles viram parte do show, não motivo pra cancelar o formato.

Dá pra replicar esse roteiro numa reunião interna, sem palco de evento?

Dá, e costuma funcionar até melhor, porque o problema é real da própria empresa, não hipotético pra plateia externa. O ajuste é reduzir o tempo total pra uns 10-12 minutos e escolher a dor com o time antes de gravar tela.

O objetivo muda: numa palestra, a demo convence quem está de fora. Numa reunião interna, ela reduz o medo do próprio time de usar a ferramenta no dia a dia. Ver o gestor construindo algo real, com erro e correção ao vivo, tira a IA do campo abstrato e coloca no campo do “eu também consigo tentar”.

O roteiro de 4 blocos se mantém: colher a dor (2-3 min), montar o prompt junto (2-3 min), construir narrando (5-6 min) e mostrar funcionando (1-2 min). O formato é o mesmo, só o palco muda.

FAQ

Quanto tempo leva pra montar um app do zero numa palestra? O roteiro leva 15 minutos, do primeiro minuto colhendo a dor da plateia até o QR code funcionando na tela. Isso não inclui o preparo prévio do palestrante, que exige várias rodadas de treino com temas hipotéticos diferentes, pra reduzir o risco de travar nos 8 minutos de construção. O tempo em cima do palco é fixo, o preparo por trás é o que garante que ele funcione.

Qual ferramenta a gente usa pra fazer o app ao vivo? Depende do tipo de app que você quer construir na hora. Pra ferramenta simples de uso pessoal, Claude Code resolve direto no terminal. Pra um app com tela e formulário que várias pessoas vão usar depois, como o exemplo da fila de espera do salão, Lovable entrega mais rápido uma interface pronta pra publicar. A escolha entra já no bloco 2, junto com o prompt, então você não precisa decidir sozinho antes do evento.

E se a plateia escolher um tema impossível de fazer em 15 minutos? A pergunta do bloco 1 já limita o escopo, pedindo um processo específico, não um sistema completo. Quando sai um pedido grande demais, o palestrante recorta na hora, com transparência: “isso dá pra fazer o núcleo agora, o resto fica pra uma segunda versão”. A plateia entende, porque é assim que funciona um projeto real de tecnologia. Se for você conduzindo a demo, o segredo é recortar com naturalidade, sem parecer que a IA falhou em algo.

O app construído ao vivo funciona de verdade depois da palestra? Funciona como protótipo funcional, não como sistema pronto pra produção com todos os cuidados de segurança e volume real. Ele guarda dado, mostra tela, responde ação, tudo de verdade. O que falta pra virar produto definitivo é o de sempre depois de um protótipo: revisão de segurança, teste de carga, ajuste fino. A demo prova que o caminho funciona, não substitui deixar pronto pra escala.

Precisa de internet muito boa pra fazer essa demo? Precisa de internet estável, não necessariamente rápida. O maior risco não é velocidade baixa, é queda de conexão no meio da construção. Por isso a prática é sempre testar a rede do local antes do evento e levar um ponto de internet móvel de backup, mesmo quando o organizador garante que a rede é boa. Se você for apresentar, faz esse teste pessoalmente, não confia só no relato de terceiros.

Dá pra fazer essa demo numa reunião de time, sem ser em palco de evento? Dá, e o ajuste é simples: reduzir o tempo pra uns 10-12 minutos e escolher um problema real da própria operação, com alguém do time sugerindo a dor em vez da plateia externa. O efeito muda de propósito: em palestra, a demo convence quem está de fora; em reunião interna, reduz o medo do próprio time de tentar usar a ferramenta.

Bora testar esse roteiro no seu próximo evento ou reunião?