KISS o Muori: Perché gli Ingegneri Senior Falliscono nelle Startup

La mia prima startup è stata un fallimento, e anche diverse startup vicine sono fallite. Avevamo: $100K in crediti GCP, un ingegnere fondatore che aveva costruito sistemi in aziende, e go-to-market. E abbiamo fallito, non perché l'abbiamo costruita male, ma perché l'abbiamo costruita bene. Questo era il problema.

Mentre passavamo tempo a lottare con quello che sembrava uno stack tecnologico "non ottimale", abbiamo perso la cosa più importante: tempo, slancio e strategicamente un'opportunità.

Questa storia non riguarda persone senza buon senso. Io avevo buon senso, e sapevamo che dovevamo mantenere le cose semplici. Ma quando il tuo modello mentale non si adatta alla situazione, tutto il tuo buon senso viene spazzato via. Prendi decisioni "corrette" che ti uccidono.

Questa non è nemmeno una storia di cattiva ingegneria. Riguarda come la buona ingegneria uccide le startup. Come l'esperienza stessa che ti rende senior diventa la tua più grande responsabilità. Come "fare le cose nel modo giusto" o anche "farle in modo semplice" spesso significa farle nel modo sbagliato.

Questo articolo presenta modelli mentali per aiutarti a prendere le giuste decisioni ed evitare quelle sbagliate che ho preso io.

:::tip A chi è rivolto: ingegneri senior che avviano o si uniscono a startup in fase iniziale. Se hai trascorso più di 5 anni in aziende o Big Tech, questo è il tuo avvertimento.

:::

\

Modello Mentale #1 - L'Infrastruttura "Gratuita" è la Più Costosa

$100K in crediti GCP sembrano un regalo, ma è una trappola. Ti spinge verso l'over-engineering perché "è già pagato". Ottieni istanze di calcolo, bilanciatori di carico, registri di container e strumenti aziendali che richiedono configurazioni aziendali. Di cosa hai bisogno? Un pulsante "push to deploy".

Certo, puoi costruire flussi di lavoro "deploy da GitHub a VM" su GCP/AWS/Azure. Alcuni prodotti ci si avvicinano. Ma richiede passaggi extra: configurare Cloud Build, impostare ruoli IAM, scrivere script di deployment, gestire segreti e configurare controlli di integrità. Bruci tempo costruendo infrastrutture di deployment prima di distribuire prodotti reali.

Nel frattempo, piattaforme come Railway o Fly.io ti danno ciò di cui le startup hanno realmente bisogno: una VM persistente con deployment start-and-go da GitHub. Facile come può essere: fai push del tuo codice e viene distribuito. VM pronta all'uso con variabili d'ambiente, SSL, bilanciatori di carico, log, ecc. Non è "gratuita", ma è pronta.

I crediti gratuiti ti spingono verso l'over-engineering perché "è già pagato". Ti convinci di risparmiare denaro mentre spendi la tua risorsa più preziosa: il tempo.

\

Modello Mentale #2 - "Minimo" <> "Semplice"

Il tradizionale principio KISS ci dice di mantenere il nostro software semplice. Ma nelle startup, quello è l'obiettivo sbagliato. Non dovresti mantenere semplice il tuo SOFTWARE; dovresti mantenere semplici le tue SOLUZIONI.

La vera semplicità dovrebbe essere misurata dallo sforzo totale, non dalla complessità del codice:

Sforzo Totale = Costruzione Iniziale + Manutenzione + Debugging + Aggiunta Funzionalità + Aggiornamenti di Sicurezza + Modifiche di Scalabilità

Quando costruisci da zero, possiedi tutti questi per sempre. Quando usi un servizio, la maggior parte di questi diventa zero. Il servizio di terze parti "gonfiato" è in realtà la soluzione semplice perché minimizza lo sforzo totale.

Il Mio Esempio OAuth

Il nostro ingegnere fondatore ha deciso di costruire OAuth da zero invece di utilizzare una "libreria sconosciuta". Una settimana dopo, ha inviato una PR: implementazione pulita di OAuth con token JWT, rotazione dei token di aggiornamento, gestione delle sessioni e controllo degli accessi basato sui ruoli. Nessuna dipendenza, nessun vendor lock-in, solo codice che controllavamo.

Non ho rifiutato la PR. E questo è stato un errore. Buttare via una settimana di lavoro avrebbe distrutto il morale. Ma crea complessità di codice e lo mette sui binari sbagliati. Inoltre, non discutere l'approccio in anticipo è stato il nostro vero errore. Abbiamo lasciato che l'orgoglio ingegneristico prendesse una decisione strategica.

Poi, un cliente aveva bisogno di Microsoft OAuth e Google OAuth. L'implementazione personalizzata significava giorni di refactoring, rotazione dei token di aggiornamento, casi limite, RBA e altre cose. Ogni aggiunta "semplice" richiedeva una profonda comprensione della nostra autenticazione personalizzata. Ogni aggiornamento di sicurezza era nostro da implementare. Ogni nuovo requisito era nostro da codificare.

Principi

Errore classico dell'ingegnere senior: ottimizzare per il controllo invece che per i risultati. Nelle startup, la realtà richiede di invertire completamente il modo di pensare degli ingegneri senior:

1. SMETTI di pensare: "Questo è solo qualche giorno di codifica" \n INIZIA a pensare: "Questi sono alcuni giorni in cui NON codifico il mio prodotto reale"
2. SMETTI di pensare: "Posso costruire questo semplicemente" \n INIZIA a pensare: "Posso risolvere questo semplicemente non costruendolo"
3. SMETTI di pensare: "I servizi di terze parti aggiungono complessità" \n INIZIA a pensare: "I servizi di terze parti assorbono complessità"

\

\

Modello Mentale #3 - Scelte di Comfort

Abbiamo scelto Angular perché il nostro ingegnere fondatore lo conosceva profondamente. Decisione intelligente, giusto? Usa i tuoi punti di forza, distribuisci codice di qualità. Il framework era buono, MA il problema era il suo ecosistema.

La Trappola dell'Ecosistema

Angular è eccellente e il nostro ingegnere poteva costruire qualsiasi cosa con esso.

Ma "qualsiasi cosa" richiedeva tempo solo per iniziare. Configurare il deployment, l'autenticazione e i componenti UI di base significava una configurazione infinita prima di scrivere una singola funzionalità. Mentre noi facevamo debug dei temi di Angular Material, i concorrenti possono (e lo faranno) usare Next.js + Vercel e stavano già facendo onboarding degli utenti.

Confronta questo con il percorso Next.js + Vercel: distribuisci un'app scheletro con npx create-next-app il primo giorno, aggiungi l'autenticazione Clerk e i componenti shadcn/ui, distribuisci funzionalità reali il primo giorno. Stessa destinazione, viaggio completamente diverso.

Perché succede questo?

La differenza non è la qualità del framework, è l'ottimizzazione dell'ecosistema. Next.js/React è circondato da startup supportate da venture capital che costruiscono strumenti per altre startup:

• UI: shadcn/ui - copia, incolla, distribuisci
• Auth: Clerk/Supabase - configura in minuti
• Deploy: Vercel - git push equivale a produzione
• Tutto il resto: se le startup ne hanno bisogno, qualcuno ha costruito un servizio

L'ecosistema di Angular serve le imprese: potente, flessibile, infinitamente personalizzabile. Perfetto(?) per team di 50 persone e un veleno per team di 3.

\

Modello Mentale #4 - Costruisci il Core, Affitta il Contesto

Ma anche con gli strumenti giusti, c'è un'ultima trappola: la compulsione di costruire cose perché puoi, non perché dovresti. Questa trappola uccide team tecnicamente forti e più startup di quanto possiamo immaginare: costruire cose che nessuno ha chiesto perché puoi, non perché dovresti.

Abbiamo speso almeno un mese in totale su funzionalità di cui nessuno aveva bisogno. OAuth personalizzato quando esisteva Auth0. Una coda di lavoro basata su Postgres quando esistevano Redis + Celery. Terraform dal primo giorno, quando la console funzionava bene. Ogni decisione sembrava produttiva, ma ognuna era un autosabotaggio per affrontare sfide reali come parlare con i clienti o fare altro sviluppo del cliente.

Il modello è semplice: se i clienti non ti sceglieranno per questo, non costruirlo.

La Mia Regola dei $50

Se un SaaS costa meno di $50/mese, non puoi permetterti di costruirlo. Il tuo tempo è troppo costoso.

Costruire OAuth personalizzato richiede 1-2 settimane in totale di manutenzione e aggiunta di diversi provider OAuth. Ai tassi di burn delle startup, sono $5.000-$15.000 in tempo di ingegneria, o in tempo di opportunità persa. Auth0 è gratuito fino a 25.000 utenti attivi, poi $35/mese. Potresti pagare Auth0 per 35 anni con quello che costa costruirlo una volta.

Quindi, non si tratta di denaro ma di priorità e costo opportunità.

Eccezione

Secondo me, costruisci solo se non puoi imparare dagli utenti senza di esso.  Un esempio semplice è quando devi testare se gli utenti pagheranno per report generati dall'IA. Costruisci la versione più semplice che dimostri la domanda. E tutto il resto cerca di scivolare. Sì, salta l'infrastruttura, salta il "farlo bene", salta le best practice che non distribuiscono funzionalità, salta i test. Di nuovo, sii il più pigro possibile nello scrivere codice.

Cosa Uso Effettivamente

• Auth: Clerk (React-native, migliore DX) o Auth0 (orientato al B2B, pronto per l'enterprise)
• Email: Resend (developer-first) o SendGrid (collaudato)
• Analytics: PostHog (gratuito fino alla scala)
• Monitoring: Sentry (imbattibile per gli errori)
• Hosting: Cloudflare o Vercel (se tutto su Next.js)

Questi non sono endorsement ma le mie scelte personali ottimizzate per la velocità. Immagino che il tuo stack sarà diverso ma questo principio non lo sarà.

\

\

Conclusione

Gli LLM hanno reso la costruzione una merce. Qualsiasi junior con Claude può creare quel sistema di autenticazione personalizzato di cui sei così orgoglioso. Il tuo valore non è più in ciò che puoi costruire, MA è nel sapere cosa non costruire.

La leadership è la capacità di separare i segnali dal rumore. La vera anzianità significa avere la disciplina di ignorare il 90% di ciò che sai e distribuire la soluzione di oggi, non l'architettura di domani.