Verificador de Prontidão para Escala
Manchete
Transforme Seu Aplicativo em um Plano Que Pode Crescer de 5 para 5.000 Usuários, em Palavras Simples
Gancho
Envie seu aplicativo. Responda algumas perguntas. Receba o plano completo para fazê-lo crescer sem desacelerar ou travar.
Dor, em palavras simples
A maioria dos aplicativos funciona bem com 5 usuários, depois desacelera ou trava quando mais pessoas entram. O banco de dados precisa pesquisar cada linha, os mesmos dados são buscados repetidamente, e ninguém testou o que acontece com 1.000 usuários de uma vez. A solução não é primeiro um servidor maior. A solução é um plano: indexar os dados, armazenar em cache o que é usado com frequência, testar a carga e hospedar onde possa crescer.
O que você recebe
Uma verificação de prontidão para escala, seguida de um plano de escala, feito apenas para o seu aplicativo. A verificação descobre o que vai quebrar primeiro. O plano fornece correções de rascunho para revisão, nunca uma alteração ao vivo por si só.
Para quem é isso
Fundadores sem conhecimento técnico, que querem saber se seu aplicativo pode crescer e o que consertar primeiro, em palavras simples. Pequenos empresários com um aplicativo ou web app que está ganhando mais usuários. Freelancers e construtores que precisam de um plano de escala claro para entregar a um desenvolvedor, com indexação, cache, teste de carga e hospedagem.
Por que isso economiza dinheiro
Consertar a escala no início é mais barato do que consertar uma falha depois. Um plano claro impede que o construtor adivinhe, recrie o banco de dados ou compre um servidor maior que você ainda não precisa.
Técnico, para programadores
Plano de escala estruturado com lista de índices de banco de dados, plano de cache com chaves e expiração, plano de teste de carga com níveis de usuário e ponto de ruptura, e plano de hospedagem com notas de escala, pronto para informar Claude, Cursor ou qualquer construtor de IA, ou um desenvolvedor humano. Nenhuma garantia de número de usuários e nenhuma afirmação de que um plano sozinho faz um aplicativo escalar. O plano é um rascunho para revisão do proprietário, não uma alteração ao vivo.
Propósito
Verificar se um aplicativo está pronto para crescer de alguns usuários para muitos usuários e, em seguida, criar um plano de escala para ele. A skill primeiro verifica, depois planeja. Ela não altera código, não altera o banco de dados, não executa um teste de carga ao vivo em usuários reais nem implanta nada por si só.
Como usar
Passo 1: faça ao usuário estas perguntas, uma de cada vez, em palavras simples. Passo 2: verifique o aplicativo com base nas 4 verificações de escala abaixo. Passo 3: escreva o plano de escala, rotulado RASCUNHO, NÃO AO VIVO, com correções de rascunho para as lacunas encontradas. Passo 4: execute as verificações ausentes no final e liste o que está completo, ausente ou não confirmado.
Faça estas perguntas primeiro, uma de cada vez:
- O que seu aplicativo faz, em palavras simples?
- Quem o usa agora e quantos usuários você tem hoje?
- Quantos usuários você quer que ele atenda e até quando?
- O que um usuário faz com mais frequência no aplicativo, em ordem?
- Onde seus dados estão armazenados agora, por exemplo, Supabase, Firebase, um banco de dados ou outro?
- Onde seu aplicativo está hospedado agora, por exemplo, Netlify, Vercel ou outro?
- O que está lento agora, se algo estiver, e quando parece lento?
- O que NÃO PODE quebrar, mesmo quando muitos usuários entram de uma vez?
- Você tem números reais de usuários ou os números de usuários são apenas uma meta?
- Quem fará as correções: um construtor de IA, um desenvolvedor humano ou você com ajuda?
Se o usuário não souber uma resposta, marque como Não confirmado e use a resposta mais comum para o tipo de aplicativo dele, informando isso. Não invente uma resposta.
As 4 verificações de escala
Verifique todas as 4, em ordem. Para cada verificação, registre a evidência: o arquivo, a tabela, a consulta, a configuração ou a resposta do usuário onde você a viu. Sem evidência, não há Aprovado.
1. Indexação de banco de dados
- As consultas mais usadas têm um índice, como um índice de livro, para que o banco de dados encontre linhas rapidamente, em vez de ler cada linha.
- Liste as 5 principais consultas por uso, em palavras simples, e diga para cada uma se tem índice ou não.
- Falha se uma consulta principal não tiver índice, ou se a mesma consulta for lenta com mais linhas.
- Correção de rascunho: uma lista de índices, com nome da tabela, nome da coluna e por que esse índice ajuda, para revisão do proprietário. Não crie um índice por conta própria.
2. Cache
- Dados usados com frequência e que raramente mudam são armazenados em cache, para que não sejam buscados no banco de dados toda vez.
- Liste o que está em cache agora, o que deve estar em cache e por quanto tempo, em palavras simples.
- Falha se os mesmos dados forem buscados em cada carregamento de página, sem cache, ou se os dados em cache nunca forem limpos quando mudam.
- Correção de rascunho: um plano de cache, com chave de cache, o que ela armazena, por quanto tempo vive e quando é limpa, para revisão do proprietário. Nomeie a ferramenta de cache apenas se o usuário já usar uma, por exemplo, Redis, ou diga Sugerido, não confirmado. Não configure cache por conta própria.
3. Teste de carga
- O aplicativo foi testado com muitos usuários falsos, para descobrir onde quebra primeiro, antes que usuários reais encontrem.
- Liste os níveis de usuário testados, por exemplo, 50, 500 e 5.000 usuários de uma vez, e o resultado para cada nível.
- Falha se nenhum teste de carga foi feito, ou se o teste usou apenas 5 usuários, ou se o ponto de ruptura é desconhecido.
- Correção de rascunho: um plano de teste de carga, com níveis de usuário, o que cada teste faz, o que observar e o que conta como aprovação, para revisão do proprietário. Não execute um teste de carga em usuários reais e não o execute em um aplicativo ao vivo, a menos que o usuário autorize.
4. Hospedagem que pode crescer
- A hospedagem pode crescer quando os usuários crescem, sem uma reconstrução completa.
- Liste a hospedagem atual e diga se ela escala sozinha ou se precisa de trabalho manual para crescer.
- Falha se a hospedagem for um único servidor pequeno sem plano de crescimento, ou se um pico de tráfego pararia o aplicativo.
- Correção de rascunho: um plano de hospedagem, com hospedagem atual, o que mudar e o que permanece igual, para revisão do proprietário. Prefira hospedagem simples que escala sozinha, por exemplo, Vercel ou Netlify, em vez de configurações complexas como Kubernetes ou Azure, a menos que o usuário já use uma configuração complexa e queira mantê-la. Não migre a hospedagem por conta própria.
Verificações extras
Estas não fazem parte das 4 verificações acima, mas relate-as separadamente como Notas. Não as misture na pontuação dos 4 pontos.
- Páginas lentas: liste a página mais lenta e o que a torna lenta, em palavras simples.
- Trabalho pesado: liste o trabalho que deve ser executado em segundo plano, por exemplo, enviar muitos e-mails ou criar muitos arquivos, em vez de bloquear o usuário.
- Custo: liste o que custará mais à medida que os usuários crescerem, por exemplo, leituras de banco de dados ou hospedagem, em palavras simples, sem preço inventado.
- Celular: diga se o aplicativo é usado em um telefone e se as partes lentas são piores em um telefone.
Regras rígidas
- Nunca marque Aprovado sem evidência.
- Nunca invente um número de usuário, uma velocidade, um custo, uma tabela de banco de dados, um índice, uma chave de cache ou um resultado de teste.
- Nunca afirme que o aplicativo pode lidar com 5.000 usuários, ou qualquer número, a menos que um teste de carga o tenha comprovado. Diga claramente o que foi testado e o que não foi testado.
- Nunca crie um índice, configure cache, execute um teste de carga em usuários ao vivo, migre hospedagem ou implante algo, sem uma aprovação separada do proprietário.
- Itens sugeridos devem ser marcados como Sugerido, não confirmado.
- Um plano de escala não é uma promessa de crescimento, usuários ou dinheiro.
- Mantenha o plano em frases curtas e simples. O proprietário pode não ser um leitor técnico.
Formato do plano de escala
Sempre termine com este formato, nesta ordem, rotulado RASCUNHO, NÃO AO VIVO, Aprovação do proprietário necessária:
Plano de escala: [nome do aplicativo]
Usuários hoje: [número ou Não confirmado] | Usuários alvo: [número ou Não confirmado] | Uso principal: [palavras simples]
Veredito: Pronto para crescer / Precisa de correções primeiro / Não pronto para crescer
Use Pronto para crescer apenas se não houver Falha nas 4 verificações. Caso contrário, use Precisa de correções primeiro, ou Não pronto para crescer se um bloqueador foi encontrado.
Resultados
| # | Verificação | Resultado | Evidência |
|---|---|---|---|
| 1 | Indexação de banco de dados | Aprovado / Falha / Não confirmado | tabela, consulta ou arquivo |
| 2 | Cache | Aprovado / Falha / Não confirmado | o que está em cache agora |
| 3 | Teste de carga | Aprovado / Falha / Não confirmado | nível de teste e resultado |
| 4 | Hospedagem que pode crescer | Aprovado / Falha / Não confirmado | nome da hospedagem |
Correções de rascunho, em ordem de prioridade
- Lista de índices: [tabela, coluna, por que ajuda]
- Plano de cache: [chave de cache, o que armazena, por quanto tempo, quando é limpo]
- Plano de teste de carga: [níveis de usuário, o que testar, o que conta como aprovação]
- Plano de hospedagem: [hospedagem atual, o que mudar, o que permanece igual]
Cada correção de rascunho deve ser marcada como RASCUNHO, NÃO AO VIVO, Aprovação do proprietário necessária.
O que vai quebrar primeiro
- [A primeira coisa que vai quebrar à medida que os usuários crescerem, em palavras simples, com evidência]
Passos do proprietário, precisa do cliente
- [Por exemplo: confirmar o número alvo de usuários]
- [Por exemplo: aprovar a lista de índices antes de ser criada]
- [Por exemplo: escolher um horário para o teste de carga, não em usuários ao vivo]
Notas
- [Qualquer nota da seção Verificações extras, ou Nenhuma.]
O que não foi verificado e por quê
- [Por exemplo: o teste de carga não pôde ser executado sem a aprovação do proprietário.]
Verificações ausentes
Após o plano, execute estas 6 verificações e liste o resultado para cada uma:
- As 5 principais consultas listadas?
- Lista de índices criada para as lacunas?
- Plano de cache criado, com chaves e expiração?
- Plano de teste de carga criado, com níveis de usuário?
- Plano de hospedagem criado?
- Número alvo de usuários confirmado pelo proprietário, ou marcado como Não confirmado?
Liste os resultados como Completo, Ausente ou Não confirmado. Não adicione um item ausente sem a aprovação do proprietário.