Een tech stack kiezen voor uw eerste SaaS: een eerlijke gids voor oprichters

Vraag tien engineers welke tech stack u voor uw eerste SaaS zou moeten gebruiken en u krijgt vijftien antwoorden, drie ervan met de stelligheid van een geloofsovertuiging. De meeste van die antwoorden kloppen — voor degene die ze geeft. Geen ervan gaat over u, uw financiële ruimte, of de klanten die u nog niet hebt binnengehaald. Als u als oprichter naar deze beslissing staart en zich een beetje misselijk voelt, dan is dit wat niemand hardop zegt: de stack telt veel minder dan u is wijsgemaakt, en de paar manieren waarop hij wél telt, zijn niet de dingen waarover mensen online ruziën.

Ik heb een flink aantal startende oprichters geholpen om van een presentatie naar een product te gaan waar echte mensen voor betalen. Bijna niemand van hen was technisch. Bijna allemaal kwamen ze aanzetten met een angstaanjagende hoeveelheid stack-folklore al opgezogen — dat ze microservices nodig hadden, dat één framework "dood" was, dat een verkeerde keuze hen zou ruïneren. En bijna elke keer bleek de stack een van de minst belangrijke beslissingen te zijn die ze dat jaar namen. Wat projecten de das om deed, was scope, onduidelijk eigenaarschap, en het mooi bouwen van het verkeerde ding. Nooit het framework.

Dit is dus de gids die ik die oprichters geef voordat we ook maar één regel code schrijven. Hij zal u niet vertellen om één specifieke stack te gebruiken, want iedereen die dat belooft zonder uw bedrijf te kennen, verkoopt iets. In plaats daarvan geeft hij u een manier van denken — zodat u, wat u ook kiest of wat uw team ook voorstelt, het als een volwassene kunt toetsen in plaats van zenuwachtig mee te knikken.

Waarom deze beslissing moeilijker voelt dan ze is

De stack-vraag voelt enorm omdat het de eerste onomkeerbaar klinkende keuze is die u maakt, en ze is verpakt in een taal die u niet spreekt. Woorden als Postgres, React, Kubernetes, serverless worden rondgegooid alsof kiezen tussen die dingen is als het kiezen van het fundament van een gebouw — kies verkeerd en de hele boel stort in.

Maar software is geen gebouw. Het lijkt veel meer op een keuken die u kunt verbouwen terwijl u nog kookt. Succesvolle bedrijven herschrijven voortdurend delen van hun stack; de versie van een product die zijn eerste honderd klanten vindt, is bijna nooit de versie die zijn eerste honderdduizend bedient. Het doel van uw eerste stack is niet om eeuwig mee te gaan. Het is om u snel genoeg te laten bouwen, veranderen en uitbrengen om te leren of iemand dit überhaupt wil. Dat is een compleet andere — en veel lagere — lat dan "perfect voor het volgende decennium".

Zodra u dat accepteert, halveert de druk. U probeert niet langer de toekomst te voorspellen. U probeert een redelijke, omkeerbare gok te maken die u naar een werkend product en betalende gebruikers brengt. En redelijke gokken zijn iets wat een niet-technische oprichter heel goed kan beoordelen.

Wat een "stack" eigenlijk is, in gewone taal

Voordat u iets beslist, helpt het om het woord te ontmythologiseren. Een tech stack is gewoon de verzameling tools die wordt gebruikt om uw software te bouwen en te draaien. U kunt het opdelen in vier lagen, en u hoeft er geen enkele diepgaand van te begrijpen — u hoeft alleen te weten dat ze bestaan.

• De frontend — wat gebruikers zien en aanklikken in hun browser of app. Dit is het deel waarop iedereen u beoordeelt.
• De backend — de logica en regels die op een server draaien: wie wat mag doen, wat er gebeurt als ze het doen, hoe geld stroomt.
• De database — waar uw informatie daadwerkelijk leeft: gebruikers, bestellingen, abonnementen, alles wat u kapot zou maken als u het verloor.
• De infrastructuur — de servers en diensten die al het bovenstaande online, geback-upt en om 3 uur 's nachts bereikbaar houden.

Als iemand zegt "we gebruiken een moderne JavaScript-stack" of "Rails op Postgres", dan beschrijven ze keuzes over deze vier lagen heen. Dat is alles. Elke SaaS, van een zijproject met twee mensen tot een beursgenoteerd bedrijf, is een of andere versie van deze vier dingen op elkaar gestapeld. De groots klinkende architectuurdiagrammen zijn precies dit, getekend met meer vakjes.

De dingen die er echt toe doen (en de dingen die dat niet doen)

Hier gaat de meeste stack-advisering mis: ze optimaliseert voor dingen die uw eerste twee jaar niet beïnvloeden en negeert de dingen die dat wel doen. Laat ik over beide lijsten eerlijk zijn.

Wat er echt toe doet

Wie het kan bouwen en onderhouden. De allerbelangrijkste factor is niet de technologie — het zijn de mensen. De beste stack voor u is die waarin uw team (of de partner die u inhuurt) vandaag de dag daadwerkelijk vlot kan werken. Een "perfecte" stack die maar één zeldzame specialist begrijpt, is een slechtere keuze dan een saaie die elke competente ontwikkelaar kan oppakken. Werving en continuïteit verslaan theoretische elegantie elke keer.

Hoe snel u dingen kunt veranderen. In het begin zit u voortdurend mis over uw product. De echte taak van de stack is om van mening veranderen goedkoop te maken. Volwassen, goed gedocumenteerde tools met grote gemeenschappen laten u snel bewegen, omdat antwoorden op uw problemen al bestaan. Bleeding-edge tools maken van u degene die de bugs ontdekt.

Of u ervoor kunt werven. Kies iets obscuurs en u koppelt uw toekomst aan wie het ook bouwde. Kies iets gangbaars en saais en u kunt altijd de volgende ontwikkelaar, het volgende bureau, de volgende persoon vinden om het over te nemen. Saai is een pluspunt wanneer uw bedrijf ervan afhangt.

Wat er veel minder toe doet dan men zegt

Pure prestaties en "schaal". U hebt geen schaalprobleem. U hebt een niemand-gebruikt-het-nog-probleem, wat het tegenovergestelde probleem is. Architecturen ontworpen voor miljoenen gebruikers vertragen u wanneer u er elf hebt. De beroemde bedrijven die u nadoet, bouwden eerst de eenvoudige versie en herbouwden later, gefinancierd door succes. U zou hetzelfde moeten doen.

Welk specifiek framework dit jaar "wint". Frameworks stijgen en dalen op een modecyclus die bijna niets te maken heeft met of ze uw facturatie-SaaS goed bouwen. Elk van de gangbare, breed gebruikte opties doet het werk. De trend is ruis; kies uit het saaie, populaire midden en ga verder.

Waarom "saaie" technologie meestal wint

Er heerst een stille wijsheid onder ervaren bouwers die nieuwkomers teleurstellend vinden: de beste technologie voor een nieuw bedrijf is meestal de saaie, bewezen, ietwat onmodieuze soort. Niet omdat nieuwe tools slecht zijn, maar omdat elke keuze die u maakt een beperkt budget aan nieuwheid uitgeeft — het aantal onbekende, niet-ondersteunde, verrassende dingen dat uw kleine team tegelijk aankan.

Besteed dat budget aan het ding dat uw bedrijf bijzonder maakt — het eigenlijke product, het inzicht dat alleen u hebt. Geef het niet uit aan een database waar niemand van gehoord heeft, alleen om modern te voelen. Een saaie, volwassen stack betekent dat problemen al eerder zijn opgelost, dat er documentatie bestaat, dat werven makkelijk is, en dat de tool volgend jaar niet verdwijnt wanneer de enige beheerder de interesse verliest. Saai laat u al uw enthousiasme stoppen waar het rendeert: in de klant.

Dit is ook waar AI het beeld een beetje verandert — en niet op de manier die de hype suggereert. AI-codeerassistenten zijn dramatisch beter in saaie, populaire technologieën, omdat ze getraind zijn op een decennium aan publieke antwoorden daarover. Kies een gangbare stack en uw team (en uw tools) krijgen gratis snellere hulp. Kies iets exotisch en u staat er alleen voor, precies wanneer u zich dat het minst kunt veroorloven.

Een beslismethode die u echt kunt gebruiken

Genoeg principes. Hier is een concrete manier om tot een beslissing te komen, of u nu zelf kiest, een freelancer brieft, of beoordeelt wat een bureau voorstelt. Niets ervan vereist dat u code schrijft — alleen dat u de juiste dingen vraagt en de antwoorden weegt.

1. 1
   Begin bij het team, niet bij de techniek

   Vraag: wie bouwt en onderhoudt dit de komende twee jaar? Wat zij al goed kennen, is uw sterke standaard. Van stack wisselen om een trend na te jagen verslaat zelden vloeiendheid.
2. 2
   Kies standaard voor gangbaar en bewezen

   Kies uit het populaire, goed gedocumenteerde midden van elke laag. Als u niet snel tutorials, vacatures en grote gemeenschappen voor een tool kunt vinden, behandel dat dan als een waarschuwing, niet als een pluspunt.
3. 3
   Optimaliseer voor verandering, niet voor schaal

   Geef de voorkeur aan de keuze die het bewerken van uw product goedkoop en snel maakt. U zult herhaaldelijk misszitten over het product — de taak van de stack is om misszitten overleefbaar te maken.
4. 4
   Houd de architectuur zo eenvoudig mogelijk

   Eén database. Eén backend. Eén frontend. Geen microservices, geen slim gedistribueerd iets, totdat een echt, gemeten probleem u dwingt. Eenvoud is het doel, niet het compromis.
5. 5
   Schrijf op waarom u het koos

   Eén alinea: wie het bouwt, wat u koos, en wat er zou moeten veranderen om het te heroverwegen. Dit notitie behoedt u ervoor de beslissing telkens opnieuw te bevechten als iemand een scherpe mening leest.

Als u verder niets volgt, volg dan stap één en vier. Bouw met de mensen die u hebt, op de eenvoudigste architectuur die werkt. Die combinatie vermijdt stilletjes de twee faalmodi die de meeste eerste SaaS-producten kelderen: niemand die het kan onderhouden, en een systeem dat te ingewikkeld is voor zijn eigen omvang.

Vragen om te stellen aan wie een stack voorstelt

De meeste oprichters kiezen de stack niet alleen — een ontwikkelaar, een bureau of een bevriende CTO stelt er een voor. U hoeft de technologie niet zelf te verifiëren. U moet een handvol vragen stellen en luisteren naar hoe ze antwoorden. Zelfverzekerde antwoorden in gewone taal zijn een goed teken. Defensief jargon niet.

• "Waarom dit, en niet de saaie populaire optie?" — een goed antwoord gaat over uw specifieke behoeften, niet over wat trendy is.
• "Als jij door een bus werd geschept, hoe makkelijk zou iemand anders dit dan kunnen overnemen?" — het antwoord onthult hoe zeldzaam en riskant de keuze is.
• "Wat is de eenvoudigste versie van deze architectuur die nog steeds werkt?" — let op of ze naar eenvoud of naar complexiteit grijpen.
• "Hoe makkelijk wordt het om de volgende ontwikkelaar hiervoor te werven?" — gangbare vaardigheden betekenen een gezonde markt; exotische vaardigheden betekenen afhankelijkheid.
• "Wat gebeurt er als we over drie maanden een kernfunctie moeten veranderen?" — u wilt horen dat verandering goedkoop is, niet gevreesd.

Veelvoorkomende valkuilen die op goede ideeën lijken

Een paar patronen komen zo vaak voor dat ze het waard zijn om te benoemen, want elk voelt op het moment zelf verantwoordelijk en kost u later veel.

Bouwen voor een schaal die u niet hebt. De drang om het "goed te doen" brengt oprichters ertoe te architecteren voor miljoenen gebruikers voordat ze er tien hebben. Elk stukje van dat toekomstbestendig maken is complexiteit waarvoor u nu betaalt, in tijd en geld, om een probleem op te lossen dat misschien nooit komt. Bouw voor de volgende honderd gebruikers. Herarchitecteer wanneer groei het noodzakelijk maakt — en laat het een fijn probleem zijn.

Het nieuwste najagen. Een glimmend framework dat vorige maand is uitgebracht, heeft geen track record, dunne documentatie en een minuscule gemeenschap. U zult uw nachten doorbrengen met het debuggen van de tool in plaats van het bouwen van uw product. Laat anderen de early adopters zijn; u hebt een bedrijf om uit te brengen.

Uitbesteden aan wie het goedkoopst is, op wat zij ook maar verkiezen. De laagste offerte komt vaak met een obscure stack die alleen dat ene team kent. De dag dat u uit elkaar gaat, wordt uw product een eiland dat niemand anders kan bereiken. Vooraf goedkoop, later rampzalig. Sta op gangbare, werfbare technologie, zelfs wanneer u uitbesteedt — juist wanneer u uitbesteedt.

Wanneer het echt tijd is om uw stack te herzien

Niets hiervan betekent "nooit veranderen". Het betekent veranderen om echte redenen, gemeten, niet ingebeeld. U weet dat het echt tijd is om uw stack te laten evolueren wanneer concrete signalen opduiken — niet wanneer een blogpost u angstig maakt.

Merk het patroon op: echte redenen gaan over gemeten pijn in uw daadwerkelijke bedrijf. Valse redenen gaan over mode, vergelijking en rusteloosheid. Wanneer een echt signaal wél verschijnt, verandert u één stuk per keer — niet de hele stack in een heroïsche herschrijving die alles zes maanden lang stillegt. Evolutie, geen revolutie.

Veelgestelde vragen