Å velge en teknologistakk til din første SaaS: en grunders ærlige guide

Spør ti ingeniører hvilken stakk du bør bruke til din første SaaS, og du får femten svar, tre av dem levert med religiøs overbevisning. De fleste av disse svarene er riktige — for den som gir dem. Ingen av dem handler om deg, kassebeholdningen din eller kundene du ennå ikke har fått i hus. Hvis du er grunder som stirrer på denne beslutningen og har det litt vondt, så er her det ingen sier høyt: stakken betyr langt mindre enn du har fått inntrykk av, og de få måtene den faktisk betyr noe på, er ikke de man krangler om på nettet.

Jeg har hjulpet en god del førstegangsgrundere fra en pitch-presentasjon til et produkt som ekte mennesker betaler for. Nesten ingen av dem var tekniske. Nesten alle ankom etter å ha sugd til seg en skremmende mengde stakk-folklore — at de trengte mikrotjenester, at ett rammeverk var «dødt», at et feil valg ville dømme dem. Og nesten hver gang viste stakken seg å være en av de minst betydningsfulle beslutningene de tok det året. Det som drepte prosjekter var omfang, uklart eierskap og å bygge feil ting vakkert. Aldri rammeverket.

Så dette er guiden jeg gir disse grunderne før vi skriver en eneste linje kode. Den sier ikke at du skal bruke én bestemt stakk, for enhver som lover det uten å kjenne forretningen din, selger noe. I stedet gir den deg en måte å tenke på — slik at uansett hva du velger, eller hva teamet ditt foreslår, kan du sunnfornuft-sjekke det som en voksen i stedet for å nikke nervøst med.

Hvorfor beslutningen føles vanskeligere enn den er

Stakk-spørsmålet føles enormt fordi det er det første tilsynelatende ugjenkallelige valget du tar, og det er pakket inn i et språk du ikke snakker. Ord som Postgres, React, Kubernetes, serverless blir kastet rundt som om valget mellom dem er som å velge grunnmuren til en bygning — velg feil, og hele greia raser sammen.

Men programvare er ikke en bygning. Den er mye nærmere et kjøkken du kan bygge om mens du fortsatt lager mat. Vellykkede selskaper skriver om deler av stakken sin hele tiden; versjonen av et produkt som finner sine første hundre kunder, er nesten aldri versjonen som betjener de første hundre tusen. Målet med din første stakk er ikke å vare evig. Det er å la deg bygge, endre og publisere raskt nok til å lære om noen i det hele tatt vil ha dette. Det er en helt annen — og langt lavere — listehøyde enn «perfekt for det neste tiåret».

Når du først aksepterer det, halveres presset. Du prøver ikke lenger å forutsi fremtiden. Du prøver å gjøre en fornuftig, reverserbar innsats som bringer deg til et fungerende produkt og betalende brukere. Og fornuftige innsatser er noe en ikke-teknisk grunder absolutt kan vurdere.

Hva en «stakk» faktisk er, i klartekst

Før du bestemmer noe, hjelper det å avmystifisere ordet. En teknologistakk er bare samlingen av verktøy som brukes til å bygge og kjøre programvaren din. Du kan tenke på den i fire lag, og du trenger ikke forstå noen av dem dypt — du trenger bare å vite at de finnes.

• Frontend — det brukerne ser og klikker på i nettleseren eller appen sin. Dette er delen alle dømmer deg på.
• Backend — logikken og reglene som kjører på en server: hvem får gjøre hva, hva skjer når de gjør det, hvordan penger beveger seg.
• Databasen — der informasjonen din faktisk bor: brukere, ordrer, abonnementer, alt du ville vært knust over å miste.
• Infrastrukturen — serverne og tjenestene som holder alt det over på nett, sikkerhetskopiert og tilgjengelig klokken tre om natten.

Når noen sier «vi bruker en moderne JavaScript-stakk» eller «Rails på Postgres», beskriver de valg på tvers av disse fire lagene. Det er alt. Enhver SaaS, fra et to-manns sideprosjekt til et børsnotert selskap, er en eller annen versjon av disse fire tingene stablet sammen. De storslåtte arkitekturdiagrammene er bare dette, tegnet med flere bokser.

Tingene som faktisk betyr noe (og de som ikke gjør det)

Her går de fleste stakk-råd galt: de optimaliserer for ting som ikke påvirker de første to årene dine, og ignorerer dem som gjør det. La meg være rett på sak om begge listene.

Hva som virkelig betyr noe

Hvem som kan bygge og vedlikeholde den. Den enkeltstående største faktoren er ikke teknologien — det er menneskene. Den beste stakken for deg er den teamet ditt (eller partneren du leier inn) faktisk kan jobbe i, flytende, i dag. En «perfekt» stakk som bare én sjelden spesialist forstår, er et dårligere valg enn en kjedelig som enhver kompetent utvikler kan overta. Rekruttering og kontinuitet slår teoretisk eleganse hver gang.

Hvor raskt du kan endre ting. Tidlig vil du stadig ta feil om produktet ditt. Stakkens egentlige jobb er å gjøre det billig å ombestemme seg. Modne, godt dokumenterte verktøy med store fellesskap lar deg bevege deg raskt fordi svarene på problemene dine allerede finnes. Knivskarpt nye verktøy gjør deg til den som oppdager feilene.

Om du kan rekruttere for den. Velg noe obskurt, og du binder fremtiden din til den som bygde det. Velg noe vanlig og kjedelig, og du kan alltid finne den neste utvikleren, det neste byrået, den neste personen til å overta. Kjedelig er en fordel når forretningen din avhenger av det.

Hva som betyr langt mindre enn folk sier

Rå ytelse og «skala». Du har ikke et skaleringsproblem. Du har et ingen-bruker-det-ennå-problem, som er det motsatte problemet. Arkitekturer designet for millioner av brukere vil sinke deg når du har elleve. De berømte selskapene du etterligner, bygde den enkle versjonen først og bygde om senere, finansiert av suksess. Det bør du også.

Hvilket bestemt rammeverk som «vinner» i år. Rammeverk stiger og faller i en motesyklus som har nesten ingenting å gjøre med om de bygger faktureringa-SaaS-en din godt. Hvilket som helst av de etablerte, mye brukte alternativene gjør jobben. Trenden er støy; velg fra den kjedelige, populære midten og gå videre.

Hvorfor «kjedelig» teknologi som regel vinner

Det finnes en stille visdom blant erfarne byggere som nykommere synes er skuffende: den beste teknologien for en ny forretning er som regel den kjedelige, gjennomprøvde, litt umoderne typen. Ikke fordi nye verktøy er dårlige, men fordi hvert valg du tar, bruker av et begrenset budsjett av nyhet — antallet ukjente, ustøttede, overraskende ting det lille teamet ditt kan håndtere på én gang.

Bruk det budsjettet på det som gjør forretningen din spesiell — selve produktet, innsikten bare du har. Ikke bruk det på en database ingen har hørt om, bare for å føle deg moderne. En kjedelig, moden stakk betyr at problemer er løst før, dokumentasjon finnes, rekruttering er enkelt, og verktøyet forsvinner ikke neste år når den eneste vedlikeholderen mister interessen. Kjedelig lar deg legge all entusiasmen din der den lønner seg: hos kunden.

Det er også her KI endrer bildet litt — og ikke på den måten hypen antyder. KI-kodingsassistenter er dramatisk bedre på kjedelig, populær teknologi, fordi de ble trent på et tiår med offentlige svar om den. Velg en etablert stakk, og teamet ditt (og verktøyene dine) får raskere hjelp gratis. Velg noe eksotisk, og du er på egen hånd akkurat når du har minst råd til det.

En beslutningsmetode du faktisk kan bruke

Nok prinsipper. Her er en konkret måte å komme frem til en beslutning på, enten du velger selv, briefer en frilanser eller vurderer hva et byrå foreslår. Ingenting av det krever at du skriver kode — bare at du spør om de riktige tingene og veier svarene.

1. 1
   Ta utgangspunkt i teamet, ikke teknologien

   Spør: hvem bygger og vedlikeholder dette de neste to årene? Det de allerede kan godt, er ditt sterke standardvalg. Å bytte stakk for å jage en trend slår sjelden flyt.
2. 2
   Standarden er etablert og gjennomprøvd

   Velg fra den populære, godt dokumenterte midten av hvert lag. Hvis du ikke raskt finner veiledninger, jobber og store fellesskap for et verktøy, behandle det som en advarsel, ikke en fordel.
3. 3
   Optimaliser for endring, ikke skala

   Foretrekk valget som gjør det billig og raskt å redigere produktet ditt. Du vil ta feil om produktet gang på gang — stakkens jobb er å gjøre det overlevelig å ta feil.
4. 4
   Hold arkitekturen så enkel den kan være

   Én database. Én backend. Én frontend. Ingen mikrotjenester, ingenting smart distribuert, før et reelt, målt problem tvinger hånden din. Enkelhet er målet, ikke kompromisset.
5. 5
   Skriv ned hvorfor du valgte den

   Ett avsnitt: hvem bygger den, hva du valgte, og hva som måtte endres for at du skal revurdere. Det notatet sparer deg for å ta opp beslutningen på nytt hver gang noen leser en skarp mening.

Følger du ingenting annet, så følg steg én og fire. Bygg med menneskene du har, på den enkleste arkitekturen som virker. Den kombinasjonen unngår stille de to feiltypene som senker de fleste første SaaS-produkter: ingen som kan vedlikeholde den, og et system som er for komplisert for sin egen størrelse.

Spørsmål til den som foreslår en stakk

De fleste grundere velger ikke stakken alene — en utvikler, et byrå eller en CTO-venn foreslår en. Du trenger ikke verifisere teknologien selv. Du trenger å stille en håndfull spørsmål og lytte til hvordan de svarer. Selvsikre svar i klarspråk er et godt tegn. Defensiv sjargong er det ikke.

• «Hvorfor dette, og ikke det kjedelige populære alternativet?» — et godt svar handler om dine spesifikke behov, ikke om hva som er trendy.
• «Hvis du ble påkjørt av en buss, hvor lett kunne noen andre overtatt dette?» — svaret avslører hvor sjeldent og risikabelt valget er.
• «Hva er den enkleste versjonen av denne arkitekturen som fortsatt virker?» — følg med på om de griper etter enkelhet eller kompleksitet.
• «Hvor lett blir det å rekruttere neste utvikler for dette?» — vanlige ferdigheter betyr et sunt marked; eksotiske betyr avhengighet.
• «Hva skjer når vi må endre en kjernefunksjon om tre måneder?» — du vil høre at endring er billig, ikke fryktet.

Vanlige feller som ser ut som gode idéer

Noen få mønstre dukker opp så ofte at de er verdt å navngi, for hvert av dem føles ansvarlig der og da og koster deg dyrt senere.

Å bygge for en skala du ikke har. Trangen til å «gjøre det ordentlig» får grundere til å arkitektere for millioner av brukere før de har ti. Hver bit av den fremtidssikringen er kompleksitet du betaler for nå, i tid og penger, for å løse et problem som kanskje aldri kommer. Bygg for de neste hundre brukerne. Omarkitekter når vekst gjør det nødvendig — og la det være et lykkelig problem.

Å jage det nyeste. Et skinnende rammeverk som kom ut forrige måned, har ingen merittliste, tynn dokumentasjon og et bitte lite fellesskap. Du vil bruke nettene dine på å feilsøke verktøyet i stedet for å bygge produktet ditt. La andre være de tidlige brukerne; du har en forretning å få i mål.

Å sette ut til den billigste, på hva enn vedkommende foretrekker. Det laveste budet kommer ofte med en obskur stakk bare det ene teamet kan. Den dagen dere skilles, blir produktet ditt en øy ingen andre kan nå. Billig i starten, ruinerende senere. Insister på etablert, rekrutterbar teknologi selv når du setter ut — særlig når du setter ut.

Når det faktisk er på tide å revurdere stakken din

Ingenting av dette betyr «aldri endre». Det betyr endre av reelle grunner, målte, ikke innbilte. Du vet at det virkelig er på tide å videreutvikle stakken din når konkrete signaler dukker opp — ikke når et blogginnlegg gjør deg engstelig.

Legg merke til mønsteret: reelle grunner handler om målt smerte i den faktiske forretningen din. Falske grunner handler om mote, sammenligning og rastløshet. Når et reelt signal endelig dukker opp, endrer du én bit om gangen — ikke hele stakken i en heroisk omskriving som stopper alt i seks måneder. Evolusjon, ikke revolusjon.

Vanlige spørsmål