Software Rápido é Software Frágil: O Custo Real da Escala Que Ninguém Te Conta

Você montou um software em 3 dias. Ele funciona. E isso é o problema.

Eu preciso falar uma coisa que vai incomodar.

Se você criou um sistema em poucos dias — com IA, com low-code, com um framework novo, não importa — e ele está rodando bem com seus 10 usuários de teste, eu tenho uma notícia: você ainda não tem um produto. Você tem um protótipo com verniz de produto.

A euforia inicial de criar software rápido é real. Eu vejo isso toda semana nas mais de 300 software houses que acompanho. O dono chega empolgado: “montamos o MVP em uma semana”. Legal. Mas aí vem a pergunta que separa amador de profissional: o que acontece quando 500 pessoas usam isso ao mesmo tempo?

E a resposta, na maioria das vezes, é o silêncio. Porque ninguém testou. Ninguém planejou. E quando o primeiro cliente grande entra, o sistema cai.

O gargalo que ninguém fala: o banco de dados

Vamos direto ao ponto. O problema número um de escalabilidade em software não é o frontend. Não é o framework. Não é a linguagem de programação. É o banco de dados.

Aplicações que rodam bem com 10 usuários travam com 500. E o motivo é quase sempre o mesmo: o banco foi tratado como um detalhe, não como a fundação que ele é.

Eu vejo três padrões recorrentes nas SHs que atendo:

1. Queries sem índice — O dev escreve um SELECT que funciona perfeito no ambiente local com 100 registros. Em produção, com 500 mil registros, a mesma query leva 12 segundos. Multiplica por 50 usuários simultâneos e o banco entra em lock.
2. N+1 queries escondidas — ORMs modernos facilitam o desenvolvimento, mas escondem o custo. Um endpoint que parece simples no código pode estar fazendo 200 queries por request. Com 10 usuários, passa. Com 200, o banco não aguenta.
3. Lógica de negócio no banco — Stored procedures, triggers, views materializadas com regras de negócio embutidas. Funciona até que você precise escalar horizontalmente. Aí descobre que tudo está acoplado a uma única instância que não pode ser replicada sem reescrever metade do sistema.

O banco de dados é para armazenar e recuperar dados. Não é para rodar lógica de negócio. Não é para ser o orquestrador de processos. Quando você mistura essas responsabilidades, está criando uma bomba-relógio que vai explodir exatamente no momento em que o negócio mais precisa funcionar.

Os custos que crescem de forma não-linear

Aqui está o dado que dói de verdade.

Escalar um software não é simplesmente “contratar mais servidor”. Os custos crescem de forma não-linear, e a maioria dos founders de SH descobre isso da pior maneira possível: quando a fatura da AWS chega.

Um cenário que vejo com frequência:

• Fase 1 (0-100 usuários): servidor compartilhado, R$200/mês. Tudo funciona.
• Fase 2 (100-500 usuários): precisa de um banco dedicado, cache Redis, CDN. R$1.500/mês. Ainda administrável.
• Fase 3 (500-2000 usuários): banco precisa de réplica de leitura, load balancer, auto-scaling, monitoramento APM. R$8.000/mês. O custo quadruplicou, mas a receita não.
• Fase 4 (2000+ usuários): re-arquitetura forçada. O monolito não aguenta. Precisa quebrar em serviços. Precisa de fila de mensagens, cache distribuído, sharding de banco. R$25.000+/mês — e isso sem contar as 3 semanas de dev parado refatorando.

O problema não é gastar R$25.000. O problema é que você não planejou para isso. A arquitetura que você escolheu na Fase 1 — aquela que parecia “rápida e eficiente” — é a mesma que está te forçando a reescrever tudo na Fase 4.

Velocidade no início compra dívida técnica no final. E dívida técnica cobra juros compostos.

O mito do “escala quando precisar”

A frase mais perigosa que eu ouço em reuniões de produto é: “a gente escala quando precisar”.

Não. Você não escala quando precisa. Você escala quando já era tarde demais. Porque escalar retroativamente é ordens de magnitude mais caro e mais arriscado do que planejar escalabilidade desde o início.

Isso não significa over-engineering. Não estou dizendo para montar uma arquitetura de microsserviços para um MVP. Estou dizendo para tomar decisões de design que não fechem portas.

Exemplos práticos:

• Separar leitura de escrita desde o dia 1 — Mesmo que ambas apontem para o mesmo banco hoje, ter essa separação no código facilita adicionar uma réplica de leitura amanhã sem mudar uma linha de lógica.
• Usar cache estratégico, não cache por desespero — Cache não é band-aid para query lenta. É decisão arquitetural. Defina o que é cacheável, por quanto tempo, e como invalida. Redis com TTL aleatório não é estratégia.
• Indexar proativamente — Se uma coluna vai ser filtrada ou ordenada, indexe agora. Não espere o banco travar em produção para descobrir que faltou um índice no campo created_at da tabela que tem 2 milhões de registros.
• Monitorar desde o início — Se você não tem APM rodando em produção, você está voando cego. Datadog, New Relic, até um Grafana open-source. Qualquer coisa. Mas não espere o cliente reclamar para descobrir que sua API está respondendo em 4 segundos.

IA acelerou a criação. E acelerou o problema.

Eu preciso falar sobre o elefante na sala.

Ferramentas de IA como Claude Code, Cursor, Copilot — elas são espetaculares para criar software rápido. Eu uso diariamente. Recomendo para todo mundo. Mas elas trouxeram um efeito colateral que poucos estão discutindo: a IA democratizou a criação de software, mas não democratizou o pensamento arquitetural.

Um dev júnior hoje consegue montar um CRUD completo em 30 minutos com IA. Antes levava 2 dias. Fantástico. Mas esse CRUD tem connection pooling? Tem paginação eficiente? Tem rate limiting? Tem retry com backoff exponencial? Tem circuit breaker para dependências externas?

Na maioria das vezes, não. Porque a IA gerou o que foi pedido — e o que foi pedido foi “um CRUD que funciona”. Funcionar não é escalar. Funcionar é o mínimo. Escalar é o trabalho de verdade.

E esse é o gap que eu vejo crescendo: mais software sendo criado mais rápido, com menos planejamento arquitetural, gerando mais dívida técnica em menos tempo. O ciclo de “criar → crescer → quebrar → reescrever” está ficando mais curto. O que antes levava 2 anos agora leva 6 meses.

O que uma Software House séria faz diferente

Depois de acompanhar centenas de SHs, eu consigo identificar as que vão ter problemas de escala só olhando três coisas:

1. Como elas tratam o banco de dados — SHs maduras têm um DBA ou pelo menos um dev sênior que revisa queries antes de ir para produção. SHs imaturas tratam o banco como uma caixa preta que “resolve sozinha”.
2. Quando elas começam a medir — SHs maduras têm métricas de performance desde o primeiro deploy. SHs imaturas só instalam monitoramento quando o primeiro cliente reclama.
3. Como elas precificam escala — SHs maduras incluem custos de infraestrutura na precificação do produto. SHs imaturas cobram pelo desenvolvimento e descobrem depois que o hosting come toda a margem.

A escala não é um problema técnico. É um problema de gestão e planejamento. A tecnologia resolve. O que falta é a decisão de resolver antes que vire urgência.

O que eu penso

Software rápido é software frágil — até que você prove o contrário.

E provar o contrário significa investir em três coisas que não são sexy, não aparecem em demo, e ninguém posta no LinkedIn: arquitetura de banco, monitoramento de performance, e planejamento de custos de infraestrutura.

Se seu sistema roda bem com 10 usuários, parabéns. Agora simule 500. Simule 2000. Olhe para o tempo de resposta do seu banco. Olhe para o custo projetado quando triplicar a base. Olhe para as queries que o ORM está gerando por baixo dos panos.

A euforia de criar rápido é válida. Mas a maturidade de construir para durar é o que separa software house de fundo de quintal de empresa de tecnologia séria.

Não existe atalho para escalabilidade. Existe planejamento ou retrabalho. E retrabalho sempre custa mais.

Esse artigo foi inspirado pelo vídeo Software Rápido: O Custo Real da Escala do meu canal no YouTube.