KISS ou morre: Por que engenheiros seniores falham em Startups

A minha primeira startup foi um fracasso, e várias startups vizinhas também falharam. Tínhamos: $100K em créditos GCP, um engenheiro fundador que tinha construído sistemas em empresas, e go-to-market. E falhámos, não porque construímos mal, mas porque construímos bem. Esse foi o problema.

Enquanto gastávamos tempo lutando com o que parecia uma stack tecnológica "não otimizada", perdemos o mais importante: tempo, momentum e estrategicamente uma oportunidade.

Esta história não é sobre pessoas sem bom senso. Eu tinha bom senso, e sabíamos que devíamos manter as coisas simples. Mas quando o seu modelo mental não se adequa à situação, todo o seu bom senso desaparece. Toma decisões "corretas" que te matam.

Isto também não é uma história sobre má engenharia. É sobre como a boa engenharia mata startups. Como a própria experiência que te torna sénior se torna a tua maior responsabilidade. Como "fazer corretamente" ou mesmo "fazer de forma simples" é muitas vezes fazer errado.

Este artigo apresenta modelos mentais para te ajudar a tomar as decisões certas e evitar as erradas que eu cometi.

:::tip Para quem é isto: engenheiros seniores que estão a começar ou a juntar-se a startups em fase inicial. Se passou 5+ anos em empresas ou Big Tech, este é o seu aviso.

:::

\

Modelo Mental #1 - Infraestrutura "Gratuita" É a Mais Cara

$100K em créditos GCP parece um presente, mas é uma armadilha. Empurra-te para a sobre-engenharia porque "já está pago". Recebes instâncias de computação, balanceadores de carga, registos de contentores e ferramentas empresariais que requerem configuração empresarial. O que precisas de obter? Um botão de "push to deploy".

Claro, podes construir fluxos de trabalho "deploy from GitHub to VM" no GCP/AWS/Azure. Alguns produtos chegam perto. Mas requer passos extra: configurar o Cloud Build, configurar funções IAM, escrever scripts de implementação, gerir segredos e configurar verificações de saúde. Gastas tempo a construir infraestrutura de implementação antes de implementar produtos reais.

Enquanto isso, plataformas como Railway ou Fly.io dão-te o que as startups realmente precisam: uma VM persistente com implementação start-and-go a partir do GitHub. Tão fácil quanto possível: fazes push do teu código, e ele é implementado. Apenas uma VM pronta a usar com variáveis de ambiente, SSL, balanceadores de carga, logs, etc. Não é "gratuito", mas está pronto.

Créditos gratuitos empurram-te para a sobre-engenharia porque "já está pago". Convences-te de que estás a poupar dinheiro enquanto gastas o teu recurso mais valioso: tempo.

\

Modelo Mental #2 - "Mínimo" <> "Simples"

O princípio tradicional KISS diz-nos para manter o nosso software simples. Mas em startups, esse é o alvo errado. Não deves manter o teu SOFTWARE simples; deves manter as tuas SOLUÇÕES simples.

A verdadeira simplicidade deve ser medida pelo esforço total, não pela complexidade do código:

Esforço Total = Construção Inicial + Manutenção + Depuração + Adição de Funcionalidades + Atualizações de Segurança + Alterações de Escala

Quando constróis do zero, és dono de todos estes para sempre. Quando usas um serviço, a maioria destes torna-se zero. O serviço de terceiros "inchado" é na verdade a solução simples porque minimiza o esforço total.

O Meu Exemplo de OAuth

O nosso engenheiro fundador decidiu construir OAuth do zero em vez de usar uma "biblioteca desconhecida". Uma semana depois, ele submeteu um PR: implementação limpa de OAuth com tokens JWT, rotação de tokens de atualização, gestão de sessão e controlo de acesso baseado em funções. Sem dependências, sem bloqueio de fornecedor, apenas código que controlávamos.

Eu não neguei o PR. E isso foi um erro. Deitar fora uma semana de trabalho esmagaria a moral. Mas cria complexidade de código e coloca-o nos trilhos errados. Além disso, não discutir a abordagem antecipadamente foi o nosso verdadeiro erro. Deixámos o orgulho de engenharia tomar uma decisão estratégica.

Depois, um cliente precisava de Microsoft OAuth e Google OAuth. A implementação personalizada significou dias de refatoração, rotação de tokens de atualização, casos extremos, RBA e outras coisas. Cada adição "simples" requeria um entendimento profundo da nossa autenticação personalizada. Cada atualização de segurança era nossa para implementar. Cada novo requisito era nosso para codificar.

Princípios

Erro clássico de engenheiro sénior: otimizar para controlo em vez de resultados. Em startups, a realidade requer inverter completamente como os engenheiros seniores pensam:

1. PARE de pensar: "Isto são apenas alguns dias de codificação" \n COMECE a pensar: "Estes são alguns dias a NÃO codificar o meu produto real"
2. PARE de pensar: "Posso construir isto simplesmente" \n COMECE a pensar: "Posso resolver isto simplesmente não construindo"
3. PARE de pensar: "Serviços de terceiros adicionam complexidade" \n COMECE a pensar: "Serviços de terceiros absorvem complexidade"

\

\

Modelo Mental #3 - Escolhas de conforto

Escolhemos Angular porque o nosso engenheiro fundador o conhecia profundamente. Decisão inteligente, certo? Use os seus pontos fortes, entregue código de qualidade. A framework era boa, MAS o problema era o seu ecossistema.

A Armadilha do Ecossistema

Angular é excelente e o nosso engenheiro podia construir qualquer coisa com ele.

Mas "qualquer coisa" demorava tempo só para começar. Configurar implementação, autenticação e componentes básicos de UI significava configuração interminável antes de escrever uma única funcionalidade. Enquanto depurávamos temas do Angular Material, os concorrentes podem (e vão) usar Next.js + Vercel e já estavam a integrar utilizadores.

Compare isso com o caminho Next.js + Vercel: implementar uma aplicação esqueleto com npx create-next-app no primeiro dia, adicionar autenticação Clerk e componentes shadcn/ui, entregar funcionalidades reais no primeiro dia. Mesmo destino, jornada completamente diferente.

Por que isto acontece?

A diferença não é a qualidade da framework, é a otimização do ecossistema. Next.js/React está rodeado por startups apoiadas por capital de risco construindo ferramentas para outras startups:

• UI: shadcn/ui - copiar, colar, entregar
• Auth: Clerk/Supabase - configurar em minutos
• Deploy: Vercel - git push equivale a produção
• Todo o resto: Se as startups precisam, alguém construiu um serviço

O ecossistema Angular serve empresas: poderoso, flexível, infinitamente personalizável. Perfeito(?) para equipas de 50 e um veneno para equipas de 3.

\

Modelo Mental #4 - Construa o Core, Alugue o Contexto

Mas mesmo com as ferramentas certas, há uma armadilha final: a compulsão de construir coisas porque podes, não porque deves. Esta armadilha mata equipas tecnicamente fortes e mais startups do que podemos imaginar: construir coisas que ninguém pediu porque podes, não porque deves.

Gastámos pelo menos um mês no total em funcionalidades que ninguém precisava. OAuth personalizado quando Auth0 existia. Uma fila de trabalhos baseada em Postgres quando Redis + Celery existiam. Terraform desde o primeiro dia, quando a consola funcionava bem. Cada decisão parecia produtiva, mas cada uma era autossabotagem para enfrentar desafios reais como falar com clientes ou fazer outro desenvolvimento de cliente.

O padrão é simples: se os clientes não te escolherem por isso, não o construas.

A Minha Regra dos $50

Se um SaaS custa menos de $50/mês, não podes dar-te ao luxo de o construir. O teu tempo é demasiado caro.

Construir OAuth personalizado leva 1-2 semanas no total de manutenção e adição de diferentes provedores OAuth. Com taxas de queima de startups, isso são $5,000-$15,000 em tempo de engenharia, ou em tempo de oportunidade perdida. Auth0 é gratuito para até 25,000 utilizadores ativos, depois $35/mês. Poderias pagar por Auth0 durante 35 anos com o que custa construí-lo uma vez.

Portanto, isto não é sobre dinheiro, mas sobre prioridades e custo de oportunidade.

Exceção

Na minha opinião, construa apenas se não puder aprender sobre os utilizadores sem isso.  Um exemplo simples é quando precisa de testar se os utilizadores pagarão por relatórios gerados por IA. Construa a versão mais simples que prove a procura. E tudo o resto tenta escapar. Sim, ignore infraestrutura, ignore "fazer corretamente", ignore as melhores práticas que não entregam funcionalidades, ignore testes. Novamente, seja o mais preguiçoso possível ao escrever código.

O Que Realmente Uso

• Auth: Clerk (React-native, melhor DX) ou Auth0 (focado em B2B, pronto para empresas)
• Email: Resend (primeiro para desenvolvedores) ou SendGrid (testado em batalha)
• Analytics: PostHog (gratuito até escalar)
• Monitorização: Sentry (imbatível para erros)
• Hospedagem: Cloudflare ou Vercel (se totalmente em Next.js)

Estas não são recomendações, mas as minhas próprias escolhas otimizadas para velocidade. Suponho que a sua stack será diferente, mas este princípio não será.

\

\

Conclusão

Os LLMs tornaram a construção uma mercadoria. Qualquer júnior com Claude pode criar esse sistema de autenticação personalizado de que tanto se orgulha. O seu valor não está mais no que pode construir, MAS em saber o que não construir.

Liderança é a capacidade de separar sinais de ruído. A verdadeira senioridade significa ter a disciplina de ignorar 90% do que sabe e entregar a solução de hoje, não a arquitetura de amanhã.