KISS of sterf: Waarom senior engineers falen bij startups

Mijn eerste startup was een mislukking, en verschillende naburige startups faalden ook. We hadden: $100K aan GCP-credits, een oprichtende engineer die systemen in ondernemingen had gebouwd, en go-to-market. En we faalden, niet omdat we het verkeerd bouwden, maar omdat we het goed bouwden. Dat was het probleem.

Terwijl we tijd besteedden aan worstelen met wat voelde als een "niet-optimale" tech stack, verloren we het belangrijkste: tijd, momentum, en strategisch een kans.

Dit verhaal gaat niet over mensen zonder gezond verstand. Ik had gezond verstand, en we wisten dat we dingen eenvoudig moesten houden. Maar wanneer je mentale model niet past bij de situatie, wordt al je gezonde verstand weggevaagd. Je neemt "correcte" beslissingen die je doden.

Dit is ook geen verhaal over slechte engineering. Het gaat over hoe goede engineering startups doodt. Hoe de ervaring die je senior maakt je grootste aansprakelijkheid wordt. Hoe "het goed doen" of zelfs "het eenvoudig doen" vaak het verkeerd doen is.

Dit artikel presenteert mentale modellen om je te helpen de juiste beslissingen te nemen en de verkeerde die ik maakte te vermijden.

:::tip Voor wie is dit: senior engineers die beginnen bij of toetreden tot startups in een vroeg stadium. Als je 5+ jaar in enterprise of Big Tech hebt doorgebracht, is dit je waarschuwing.

:::

\

Mentaal Model #1 - "Gratis" Infrastructuur Is Het Duurste

$100K aan GCP-credits lijkt een geschenk, maar het is een val. Het duwt je naar over-engineering omdat "het al betaald is." Je krijgt compute-instances, load balancers, container registries, en enterprise tools die enterprise setup vereisen. Wat heb je nodig? Een "push to deploy" knop.

Natuurlijk kun je "deploy from GitHub to VM" workflows bouwen op GCP/AWS/Azure. Sommige producten komen in de buurt. Maar het vereist extra stappen: Cloud Build configureren, IAM-rollen instellen, deployment scripts schrijven, geheimen beheren, en health checks configureren. Je verbrandt tijd met het bouwen van deployment-infrastructuur voordat je daadwerkelijke producten deployt.

Ondertussen geven platforms zoals Railway of Fly.io je wat startups echt nodig hebben: een persistente VM met start-and-go deployment vanuit GitHub. Zo eenvoudig als het kan zijn: je pusht je code, en het wordt gedeployed. Gewoon een kant-en-klare VM met omgevingsvariabelen, SSL, load balancers, logs, etc. Het is niet "gratis," maar het is klaar voor gebruik.

Gratis credits duwen je naar over-engineering omdat "het al betaald is." Je overtuigt jezelf dat je geld bespaart terwijl je je meest waardevolle bron uitgeeft: tijd.

\

Mentaal Model #2 - "Minimaal" <> "Eenvoudig"

Het traditionele KISS-principe vertelt ons om onze software eenvoudig te houden. Maar in startups is dat het verkeerde doel. Je moet niet je SOFTWARE eenvoudig houden; je moet je OPLOSSINGEN eenvoudig houden.

Echte eenvoud moet worden gemeten aan de totale inspanning, niet aan code-complexiteit:

Totale Inspanning = Initiële Bouw + Onderhoud + Debugging + Feature Toevoeging + Beveiligingsupdates + Schaalveranderingen

Wanneer je vanaf nul bouwt, ben je voor altijd eigenaar van al deze aspecten. Wanneer je een dienst gebruikt, worden de meeste hiervan nul. De "opgeblazen" dienst van derden is eigenlijk de eenvoudige oplossing omdat het de totale inspanning minimaliseert.

Mijn OAuth Voorbeeld

Onze oprichtende engineer besloot OAuth vanaf nul te bouwen in plaats van een "onbekende bibliotheek" te gebruiken. Een week later diende hij een PR in: schone OAuth-implementatie met JWT-tokens, refresh token rotatie, sessiebeheer en rolgebaseerde toegangscontrole. Geen afhankelijkheden, geen vendor lock-in, alleen code die we beheersten.

Ik wees de PR niet af. En dit was een fout. Een week werk weggooien zou het moreel verpletteren. Maar het creëert codecomplexiteit en zet het op de verkeerde rails. Bovendien was het niet vooraf bespreken van de aanpak onze echte fout. We lieten engineering-trots een strategische beslissing nemen.

Toen had een klant Microsoft OAuth en Google OAuth nodig. Aangepaste implementatie betekende dagen van refactoring, refresh token rotatie, randgevallen, RBA, en andere dingen. Elke "eenvoudige" toevoeging vereiste een diep begrip van onze aangepaste authenticatie. Elke beveiligingsupdate moesten wij implementeren. Elke nieuwe vereiste moesten wij coderen.

Principes

Klassieke senior engineer fout: optimaliseren voor controle in plaats van resultaten. In startups vereist de realiteit een complete omkering van hoe senior engineers denken:

1. STOP met denken: "Dit is slechts een paar dagen coderen" \n BEGIN met denken: "Dit is een paar dagen NIET coderen aan mijn eigenlijke product"
2. STOP met denken: "Ik kan dit eenvoudig bouwen" \n BEGIN met denken: "Ik kan dit eenvoudig oplossen door niet te bouwen"
3. STOP met denken: "Diensten van derden voegen complexiteit toe" \n BEGIN met denken: "Diensten van derden absorberen complexiteit"

\

\

Mentaal Model #3 - Comfortkeuzes

We kozen Angular omdat onze oprichtende engineer het diepgaand kende. Slimme beslissing, toch? Gebruik je sterke punten, lever kwaliteitscode. Het framework was prima, MAAR het probleem was het ecosysteem.

De Ecosysteemval

Angular is uitstekend en onze engineer kon er alles mee bouwen.

Maar "alles" kostte tijd om te beginnen. Het opzetten van deployment, authenticatie en basis UI-componenten betekende eindeloze configuratie voordat je een enkele feature kon schrijven. Terwijl wij Angular Material-thema's debugden, konden (en zouden) concurrenten met Next.js + Vercel al gebruikers aan boord nemen.

Vergelijk dat eens met het Next.js + Vercel-pad: deploy een skelet-app met npx create-next-app op dag één, voeg Clerk-authenticatie en shadcn/ui-componenten toe, lever daadwerkelijke features op dag één. Zelfde bestemming, compleet andere reis.

Waarom gebeurt dit?

Het verschil is niet de kwaliteit van het framework, het is ecosysteemoptimalisatie. Next.js/React wordt omringd door venture-backed startups die tools bouwen voor andere startups:

• UI: shadcn/ui - kopiëren, plakken, leveren
• Auth: Clerk/Supabase - configureren in minuten
• Deploy: Vercel - git push is gelijk aan productie
• Al het andere: Als startups het nodig hebben, heeft iemand een dienst gebouwd

Angular's ecosysteem dient ondernemingen: krachtig, flexibel, oneindig aanpasbaar. Perfect(?) voor teams van 50 en een vergif voor teams van 3.

\

Mentaal Model #4 - Bouw Kern, Huur Context

Maar zelfs met de juiste tools is er één laatste val: de drang om dingen te bouwen omdat je het kunt, niet omdat je het zou moeten. Deze val doodt technisch sterke teams en meer startups dan we ons kunnen voorstellen: dingen bouwen waar niemand om heeft gevraagd omdat je het kunt, niet omdat je het zou moeten.

We besteedden minstens een maand in totaal aan features die niemand nodig had. Aangepaste OAuth terwijl Auth0 bestond. Een Postgres-gebaseerde job queue terwijl Redis + Celery bestond. Terraform vanaf dag één, terwijl de console prima werkte. Elke beslissing voelde productief, maar elk was zelfondermijning om echte uitdagingen aan te gaan zoals praten met klanten of andere klantgerichte ontwikkeling.

Het patroon is eenvoudig: als klanten je er niet voor zullen kiezen, bouw het dan niet.

Mijn $50 Regel

Als een SaaS minder dan $50/maand kost, kun je het je niet veroorloven om het te bouwen. Je tijd is te duur.

Het bouwen van aangepaste OAuth kost in totaal 1-2 weken aan onderhoud en het toevoegen van verschillende OAuth-providers. Bij startup burn rates is dat $5.000-$15.000 aan engineeringstijd, of aan verloren kansen. Auth0 is gratis voor maximaal 25.000 actieve gebruikers, daarna $35/maand. Je zou 35 jaar voor Auth0 kunnen betalen met wat het kost om het één keer te bouwen.

Dus, dit gaat niet over geld maar over prioriteiten en opportuniteitskosten.

Uitzondering

Naar mijn mening, bouw alleen als je niet over gebruikers kunt leren zonder het.  Een eenvoudig voorbeeld is wanneer je moet testen of gebruikers willen betalen voor AI-gegenereerde rapporten. Bouw de eenvoudigste versie die vraag bewijst. En al het andere probeert weg te glippen. Ja, sla infrastructuur over, sla "het goed doen" over, sla best practices over die geen features opleveren, sla tests over. Nogmaals, wees zo lui mogelijk bij het schrijven van code.

Wat Ik Daadwerkelijk Gebruik

• Auth: Clerk (React-native, betere DX) of Auth0 (B2B-gericht, enterprise-ready)
• Email: Resend (developer-first) of SendGrid (battle-tested)
• Analytics: PostHog (gratis tot schaal)
• Monitoring: Sentry (onverslaanbaar voor fouten)
• Hosting: Cloudflare of Vercel (als volledig op Next.js)

Dit zijn geen aanbevelingen maar mijn eigen keuzes geoptimaliseerd voor snelheid. Ik vermoed dat je stack zal verschillen maar dit principe niet.

\

\

Conclusie

LLMs hebben bouwen gestandaardiseerd. Elke junior met Claude kan dat aangepaste authenticatiesysteem maken waar je zo trots op bent. Je waarde zit niet meer in wat je kunt bouwen, MAAR in het weten wat je niet moet bouwen.

Leiderschap is het vermogen om signalen van ruis te scheiden. Ware senioriteit betekent de discipline hebben om 90% van wat je weet te negeren en de oplossing van vandaag te leveren, niet de architectuur van morgen.