A solução boa o suficiente de hoje é o gargalo de amanhã

Tem um momento específico na vida de toda solução tecnológica em que ela para de ser uma resposta e vira um problema.

Eu vi esse momento acontecer ao vivo, toda semana, por meses — antes de finalmente entender o que estava vendo.

A planilha que funcionou (por um bom tempo)

Quando assumi o ministério de acolhimento do grupo, o controle de presença era feito com papel e caneta. Um caderno, um nome por linha, uma caneta Bic. Funcionava — para 20, 30 pessoas.

Meu primeiro upgrade foi uma planilha Google. Na época, parecia o salto perfeito:

• Pesquisa instantânea por nome
• Dados na nuvem, sem risco de perder o caderno
• Dois celulares podendo editar ao mesmo tempo
• Fórmulas automáticas calculando estatísticas que antes levavam horas

A planilha foi usada por anos. Ela era genuinamente boa. Não era um paliativo — era a solução certa para o tamanho que o problema tinha naquele momento.

E aí o grupo cresceu.

O que escala revela

De 20 para 50 jovens: planilha excelente. De 50 para 150: planilha boa. De 150 para 300: planilha ok. De 300 para 500: planilha se tornou o maior problema do evento.

Mas aqui está o que é interessante: a planilha não mudou. O código continuava o mesmo, as fórmulas eram as mesmas, o Google Sheets era o mesmo. O que mudou foi o volume — e o volume expôs limitações que sempre existiram mas nunca importaram.

Uma planilha com 1.000 linhas não foi projetada para ser pesquisada por 3 pessoas ao mesmo tempo, em celulares com 3G fraco, num estacionamento, com 20 pessoas esperando. Isso não é uma falha de design — é uma falha de contexto. A planilha nunca foi feita para isso.

Toda solução é boa dentro de um envelope de condições. Escala é o que testa os limites desse envelope.

O erro que cometi — e que a maioria comete — foi ficar tentando ampliar o envelope em vez de questionar se a solução ainda era a certa.

A pergunta errada vs. a pergunta certa

Por um tempo, fiquei tentando consertar a planilha. Adicionar abas, melhorar fórmulas, criar filtros. Era a pergunta errada: "como faço essa planilha funcionar melhor?"

A pergunta certa era diferente: "qual é o problema real que precisa ser resolvido?"

O problema real não era "a planilha está lenta". O problema real era:

Como registrar a presença de centenas de pessoas em minutos, sem erro humano, com dados confiáveis?

Quando reformulei assim, a resposta ficou óbvia: digitar nomes é o gargalo. O ser humano na entrada, tentando encontrar "Gabriela" enquanto o celular trava e a fila cresce — esse é o ponto de falha. Qualquer solução que dependesse de digitação manual tinha um teto de capacidade baixo demais.

A resposta era eliminar a digitação.

A decisão de reconstruir

Decidi parar de melhorar a planilha e construir algo novo: o Parusya, um sistema web de controle de presença por QR Code.

O modelo é simples: cada participante se cadastra uma vez e recebe um QR Code pessoal. Na entrada do evento, a equipe de recepção escaneia o código com a câmera do celular. O check-in é registrado instantaneamente.

Mas simples de usar não significa simples de construir bem.

As decisões técnicas que pareciam pequenas no começo revelaram uma complexidade real durante o desenvolvimento. Uma delas merece destaque: como modelar quem é dono de quê.

A decisão de arquitetura mais importante que tomei

Minha primeira versão mental do sistema era assim: o Organizer cria eventos, cadastra a equipe, vê relatórios. Tudo pertencia ao Organizer.

O problema apareceu quando me perguntei: e se o Organizer sair do grupo?

Na primeira versão, todos os dados iam junto. A equipe perderia acesso aos eventos. O histórico ficaria preso a uma pessoa que não estava mais lá.

Isso não era um edge case — era uma situação completamente plausível num grupo voluntário com rotatividade natural.

A solução foi introduzir uma entidade intermediária: o Grupo.

Organizer → pertence a → Grupo
EventStaff → vinculada a → Grupo
Event → pertence a → Grupo
CheckIn → associado a → Event (que pertence ao Grupo)

Eventos, equipe e dados históricos pertencem ao Grupo — não à pessoa. Qualquer Organizer do Grupo enxerga e gerencia tudo. Se alguém sai, nada quebra.

Esse diagrama ficou assim no modelo de domínio:

Group "1" --> "*" Organizer : has
Group "1" --> "*" EventStaff : has
Group "1" --> "*" Event : owns
Event "*" --> "*" Tag : has
CheckIn "*" --> "1" Participant : registers
CheckIn "*" --> "1" Event : at
CheckIn "*" --> "1" EventStaff : scanned by

Foi uma mudança de três linhas no modelo conceitual. Mas salvou o sistema de um problema que eu nem sabia que ia ter.

Isso é o que arquitetura de software significa na prática: não é sobre a tecnologia mais nova. É sobre modelar o problema real antes de escrever uma linha de código.

O que a planilha me ensinou sobre produto

Existe uma ironia bonita aqui: a planilha foi uma boa solução. Ela resolveu um problema real, gerou dados que usamos em projetos interessantes — mandamos cartas para endereços coletados, mensagens para quem sumiu, convites para adorações especiais.

Mas ela também me ensinou algo que nenhuma aula de engenharia me ensinou com a mesma clareza:

Você não constrói para hoje. Você constrói para onde hoje está indo.

Ninguém monta uma startup esperando que seu banco de dados não escale. Ninguém cria uma planilha esperando que o grupo triplique de tamanho. Mas o crescimento acontece — e quando acontece, as limitações das suas escolhas anteriores aparecem todas de uma vez.

A planilha não era ruim. Era perfeita para 50 pessoas.

Para 500, o Parusya precisava existir.

A diferença entre os dois não é só tecnologia. É a pergunta que foi feita antes de construir.