APP FACTORY: backend e frontend em paralelo
O gancho (adapte com a tua voz): "Time normal: o frontend espera o backend ficar pronto. Esse squad não espera ninguém — 'backend e frontend em paralelo, contra o contrato, não um contra o outro'. Olha isso."
Checklist de preparação
Tudo isso pronto antes de ligar a câmera — grava com confiança, não improviса.
- O app que vai ser construído definido antes: escopo pequeno (3-5 funcionalidades), tecnologia escolhida (Next.js, FastAPI, etc.).
- O contrato/SCOPE escrito antes de gravar — mas deixa o arquivo fechado pro gancho, como se fosse escrever ao vivo.
- Squad App Factory configurado no Overclock e testado com uma versão menor antes.
- Deploy pronto: o app precisa ir ao ar, não só rodar local.
A estrutura que segura view até o fim
Proporções sobre a duração total — num vídeo de 10 min, 10% ≈ 1 min.
A tagline + o problema real que o squad resolve.
- Fala a tagline: "backend e frontend em paralelo, contra o contrato, não um contra o outro."
- Explica o problema: "quando você tem um time, o frontend fica esperando o backend. O squad não tem esse problema porque os dois trabalham contra o mesmo contrato — não um contra o outro."
- Declara o que vai acontecer: "vou montar o contrato agora e disparar o squad."
O contrato/SCOPE escrito ao vivo — é ele que permite o paralelismo seguro.
- Abre um arquivo de SCOPE em branco na tela.
- Escreve ao vivo: endpoints da API (nome, método, request, response), rotas do frontend (URL, componentes, dados necessários), tipos compartilhados.
- Lê o contrato completo em voz alta: "backend constrói esses endpoints. Frontend constrói essas telas que consomem esses endpoints. Os dois trabalham contra essa especificação — sem precisar um do outro."
- Dispara o squad com o contrato.
SCOPE do app [nome]: Endpoints: [POST /api/items → {name, price} → {id, name, price}; GET /api/items → [{id, name, price}]]. Telas: [/items → lista de items com nome e preço; /items/new → formulário de criação]. Tipos: Item = {id: string, name: string, price: number}. Regra: backend e frontend constroem independentemente contra essa especificação.- 💡 O contrato é o conteúdo educacional mais valioso do vídeo — mostra cada campo sendo pensado. Quem aprende a escrever SCOPE aprende a paralelizar.
Os 8+ panes construindo os dois lados simultaneamente.
- Mostra os panes abrindo: grupo do backend (implementando os endpoints), grupo do frontend (implementando as telas).
- Posiciona a janela pra mostrar os dois grupos ao mesmo tempo — "esse lado é o backend, esse é o frontend."
- Narra em tempo real: "o backend já criou o endpoint de POST, o frontend está construindo o formulário que vai consumir ele."
- Quando o backend terminar um endpoint, mostra — e aponta que o frontend não estava esperando: já estava construindo a tela.
- O momento de integração: os dois lados ficam prontos e se encontram pela primeira vez. Testa na tela.
- 💡 A cena dos dois grupos de panes trabalhando em lados diferentes da tela é a imagem central do vídeo. Mantém esse enquadramento por pelo menos 30 segundos.
Um verificador por fluxo testando o app de ponta a ponta.
- Abre o pane de review com o app funcionando.
- Testa o fluxo principal: cria um item, lista os itens, confirma que frontend e backend se comunicam.
- Anota o que ficou certo e o que precisa de ajuste.
- Faz 1-2 ajustes visíveis — mostra o ciclo de feedback.
A limitação do contrato + fecho puxando SaaS 10K.
- Diz a limitação: "contrato ruim = dois times construindo coisas que não se encaixam. Mostrei cuidado no contrato — se tivesse pressa, teria que retrabalho."
- Fecho: "app no ar. O próximo passo é garantir que ele aguenta usuário real — 4 auditores de segurança em paralelo, próximo vídeo."
O número que ancora o vídeo
Backend e frontend visíveis crescendo simultaneamente no grid + o app funcionando ao final com os dois lados integrados.
A limitação dita de frente
A qualidade do contrato define tudo: contrato ruim = dois times construindo coisas que não se encaixam. O cuidado na fase de SCOPE é o que torna o paralelismo possível.
Puxando o próximo vídeo
"App no ar. Mas app que vai receber usuário de verdade precisa de cofre — no próximo vídeo, 4 auditores de segurança atacam esse app ao mesmo tempo."
O que trava — e como sair
Todo builder bate nesses pontos. Saber antes economiza uma regravação.
| O erro | O fix |
|---|---|
| O frontend e o backend não se integraram ao final — os tipos não bateram. | O tipo compartilhado no contrato é o que previne isso. Se no tipo do contrato o backend retorna `{id: string}` e o frontend espera `{_id: string}`, vai quebrar. Revisa os tipos antes de disparar o squad — é 5 minutos que economizam 30. |
| O contrato ficou vago e o squad gerou código que não encaixava. | Contrato bom tem: nomes exatos de campos (não "id do item", mas `itemId`), tipos explícitos (string, number, boolean), formato de request e response pra cada endpoint. Vago = rework. |
Como saber que ficou bom
O vídeo está pronto quando: (1) o contrato SCOPE aparece completo na tela antes do build começar, (2) os dois grupos (backend e frontend) são visíveis ao mesmo tempo por pelo menos 20 segundos, (3) o app roda com uma operação real (criar + listar) ao final. Se o app não roda, o vídeo não entrega.
Outras formas de gravar este roteiro
- Versão tech-específica: "backend FastAPI + frontend React em paralelo" — título com stack específica tem mais CTR pra público técnico.
- Versão simples: app de lista de tarefas (todo list) — funcionalidade universal que qualquer espectador entende, foco 100% no processo de paralelismo.
Três títulos prontos
Escolhe um, ou usa como base — número e promessa concreta sempre na frente.
| 01 | Backend e frontend AO MESMO TEMPO — o squad App Factory |
| 02 | 8 agentes construíram um app dos dois lados de uma vez |
| 03 | App Factory: o contrato primeiro, o app em paralelo depois |
Publicou e bateu 1.000 views? Comprova antes dos outros.
São 5 assinaturas Ultra pros 5 primeiros — 4 vídeos com 1.000+ views cada (ou 10.000+ num Shorts) e a vaga é sua.