Erro um: escrever uma especificação em vez de uma frase
Pessoas que já se queimaram com software ruim antes tendem a abrir o construtor e digitar um parágrafo. Sistema de notas, preferências de unidade, modo offline, esquema de cores, tudo antecipado antes mesmo da primeira resposta voltar. Parece responsável. Não é. O construtor lê sua única frase, infere o que você provavelmente quer dizer e volta com um plano em cerca de quinze segundos — "um diário de treino para escaladores" vira um registro de sessões, uma visão de acompanhamento de graus e um painel, com o sistema V de boulder e as rotas YDS escolhidos como padrão porque é isso que a maioria dos escaladores realmente usa. Ele te diz o que escolheu, ali mesmo no plano, para você corrigir em uma linha se for a exceção. Escrever o parágrafo antecipadamente não pula essa etapa. Você ainda recebe um plano, ainda precisa lê-lo, e agora gastou três minutos digitando restrições que o plano teria revelado de qualquer forma, na ordem que realmente importa para o seu build.
O plano não é um formulário com lacunas para preencher. É prosa, e você responde em prosa. "Na verdade, use graus Font, estou na Europa" é uma edição completa. Assim como "adicione um campo de parceiro/registro de segurança, eu escalo com pessoas diferentes". Cada edição regenera o plano, não o build — você está direcionando antes de a parte cara começar, não reiniciando-a. Aprovar esse plano é a última decisão que você precisa tomar. Tudo depois disso é geração e verificação.
Erro dois: ficar observando o feed como um terminal travado
O build roda no servidor, e o susto aqui é quase sempre um falso alarme: alguém fica olhando um feed de atividade parado por dois minutos e presume que travou. Não travou — está em uma fase que não produz saída visível a cada segundo, e o feed indica em qual fase você está exatamente por esse motivo. Você pode fechar a aba por completo. A execução não vive no seu navegador.
O que você deve realmente esperar varia bastante conforme o formato. O diário de escalada — algumas páginas, um modelo de dados local, nada chamando uma API externa — fica pronto em menos de três minutos, o que é típico para qualquer coisa basicamente "registre isto, mostre um gráfico daquilo, exiba uma lista". No momento em que um build precisa de um backend de verdade, autenticação, um banco de dados com relacionamentos, tarefas em segundo plano, você está falando de oito a doze minutos, porque agora há geração e migração de esquema, e a verificação roda uma segunda vez contra código de servidor em vez de apenas marcação. Jogos são ainda mais lentos, porque precisam de geração de assets: sprites, efeitos sonoros, às vezes uma segunda passagem visual se a primeira tentativa não ficar legível no tamanho em que será exibida. E o empacotamento nativo, um APK instalável de verdade, não uma webview embrulhada em um shell, passa a bola para uma cadeia de ferramentas real. Gradle, assinatura, tudo isso. Só essa etapa pode acrescentar de cinco a dez minutos a mais do que o resto, e é a fase em que um feed silencioso significa que a cadeia de ferramentas está fazendo o trabalho dela, não que algo quebrou.
O custo honesto desse modelo é que você perde o feedback instantâneo, caractere por caractere, de ver código sendo transmitido para um editor. O que substitui isso é um sistema que sobrevive ao seu laptop dormindo e ao seu wifi caindo, que você pode checar pelo celular, que continua rodando esteja você olhando ou não. Para um build de noventa segundos, essa troca quase não é percebida. Para o build de backend de doze minutos, é a diferença entre vigiar um terminal e ir tomar um café.
Erro três: confundir gerado com pronto
Esse é o erro caro. Um build que termina rápido e não foi verificado não é um build finalizado, é um rascunho que por acaso funciona — e a diferença entre essas duas coisas é onde a maioria dos construtores rápidos de sites ganha má reputação, lançando formulários sem sanitização e botões que nada consegue alcançar pelo teclado. Antes de esta plataforma chamar algo de pronto, agentes verificadores separados o revisam: código, segurança, links, SEO, acessibilidade e conformidade com o plano que você aprovou. Essa é uma passagem genuinamente separada, não o mesmo agente relendo a própria saída e concordando consigo mesmo.
A verificação de segurança caça as coisas chatas que realmente mordem as pessoas em produção: uma chave de API embutida em código do lado do cliente, um formulário aceitando entrada sem sanitização, um endpoint confiando em um ID de usuário fornecido pelo cliente em vez de derivá-lo da sessão. A verificação de acessibilidade não é um linter que você pode silenciar com um comentário — ela checa taxas de contraste reais e se os elementos interativos são alcançáveis pelo teclado.
Conformidade é a que as pessoas mais subestimam. É fácil uma passagem de geração deixar cair discretamente algo que você pediu — aquele campo de parceiro/registro de segurança da sua edição de plano, por exemplo — três arquivos depois no build, despriorizado sem que ninguém decida removê-lo. A conformidade relê o plano aprovado por você contra a saída real e pega essa lacuna. Quando encontra uma, a correção é aplicada e reverificada automaticamente; você não recebe uma lista de tarefas, você recebe ou uma correção que nunca vê ou nada de errado para começar. A mecânica do que cada verificador checa, e o que acontece quando algo falha duas vezes seguidas, está em Como os builds se verificam. A única coisa que vale a pena levar desta seção: pronto significa aprovado, não gerado. Trate essas duas coisas como a mesma afirmação e, mais cedo ou mais tarde, você vai lançar a chave exposta ou o botão inalcançável.
O que você ganha se evitar os três erros
- Um produto funcionando em uma pré-visualização real que você pode navegar clicando — uma instância de fato em execução com seus dados já conectados, não uma captura de tela de como vai ficar.
- Um fio de conversa anexado a ele, onde "deixe o cabeçalho mais escuro e adicione uma página de estatísticas" produz a versão dois ao lado da versão um. A versão antiga não desaparece; ela fica ali como um fallback enquanto a nova assume a pré-visualização ao vivo.
- Botões que fazem coisas: publicar ao vivo, baixar o código, criar instaladores nativos, enviar para uma loja. Não modais de upsell disfarçados de botões.
Esse botão de baixar o código merece uma segunda olhada, porque é o que separa uma ferramenta na qual você confiaria algo de verdade de uma que você só usaria para protótipos descartáveis. Se o código é genuinamente seu para levar, com estrutura de arquivos legível, sem aprisionamento exótico além do que você realmente pediu, então a plataforma precisa continuar conquistando sua próxima sessão em vez de descansar sobre o fato de que você já está preso dentro dela.
