At vælge en teknologistak til din første SaaS: en stifters ærlige guide

Spørg ti ingeniører, hvilken teknologistak du bør bruge til din første SaaS, og du får femten svar, tre af dem leveret med religiøs overbevisning. De fleste af de svar er rigtige — for den, der giver dem. Ingen af dem handler om dig, din pengekasse eller de kunder, du endnu ikke har fået i hus. Hvis du er stifter, der stirrer på denne beslutning og har det lidt skidt, så er her det, ingen siger højt: stakken betyder langt mindre, end du har fået indtryk af, og de få måder, den faktisk betyder noget på, er ikke dem, man skændes om online.

Jeg har hjulpet en del førstegangsstiftere fra en pitch-præsentation til et produkt, som rigtige mennesker betaler for. Næsten ingen af dem var tekniske. Næsten alle ankom efter at have suget en skræmmende mængde stak-folklore til sig — at de havde brug for mikrotjenester, at ét framework var ”dødt”, at et forkert valg ville dømme dem. Og næsten hver gang viste stakken sig at være en af de mindst betydningsfulde beslutninger, de traf det år. Det, der dræbte projekter, var omfang, uklart ejerskab og at bygge det forkerte smukt. Aldrig framework'et.

Så dette er guiden, jeg giver de stiftere, før vi skriver en eneste linje kode. Den fortæller dig ikke at bruge én bestemt stak, for enhver, der lover det uden at kende din forretning, sælger noget. I stedet giver den dig en måde at tænke på — så uanset hvad du vælger, eller hvad dit team foreslår, kan du sundfornufts-tjekke det som en voksen i stedet for nervøst at nikke med.

Hvorfor beslutningen føles sværere, end den er

Stak-spørgsmålet føles enormt, fordi det er det første tilsyneladende uigenkaldelige valg, du træffer, og det er pakket ind i et sprog, du ikke taler. Ord som Postgres, React, Kubernetes, serverless bliver kastet rundt, som om valget mellem dem er som at vælge fundamentet til en bygning — vælg forkert, og det hele styrter sammen.

Men software er ikke en bygning. Det er meget tættere på et køkken, du kan bygge om, mens du stadig laver mad. Succesfulde virksomheder omskriver dele af deres stak hele tiden; den version af et produkt, der finder sine første hundrede kunder, er næsten aldrig den version, der betjener de første hundrede tusinde. Målet med din første stak er ikke at holde for evigt. Det er at lade dig bygge, ændre og udgive hurtigt nok til at lære, om nogen overhovedet vil have det her. Det er en helt anden — og langt lavere — overligger end ”perfekt til det næste årti”.

Når du først accepterer det, halveres presset. Du forsøger ikke længere at forudsige fremtiden. Du forsøger at lave et fornuftigt, omgøreligt væddemål, der bringer dig til et fungerende produkt og betalende brugere. Og fornuftige væddemål er noget, en ikke-teknisk stifter absolut kan vurdere.

Hvad en ”stak” faktisk er, i klart sprog

Før du beslutter noget, hjælper det at afmystificere ordet. En teknologistak er bare samlingen af værktøjer, der bruges til at bygge og køre din software. Du kan tænke på den i fire lag, og du behøver ikke forstå nogen af dem dybt — du skal bare vide, at de findes.

• Frontend — det, brugerne ser og klikker på i deres browser eller app. Det er den del, alle bedømmer dig på.
• Backend — logikken og reglerne, der kører på en server: hvem må gøre hvad, hvad sker der, når de gør det, hvordan penge bevæger sig.
• Databasen — hvor dine oplysninger faktisk bor: brugere, ordrer, abonnementer, alt det, du ville være knust over at miste.
• Infrastrukturen — serverne og tjenesterne, der holder alt ovenstående online, sikkerhedskopieret og tilgængeligt klokken tre om natten.

Når nogen siger ”vi bruger en moderne JavaScript-stak” eller ”Rails på Postgres”, beskriver de valg på tværs af disse fire lag. Det er det hele. Enhver SaaS, fra et to-mands sideprojekt til en børsnoteret virksomhed, er en eller anden version af disse fire ting stablet sammen. De storladent klingende arkitekturdiagrammer er bare dette, tegnet med flere kasser.

De ting, der faktisk betyder noget (og dem, der ikke gør)

Her går de fleste stak-råd galt: de optimerer for ting, der ikke påvirker dine første to år, og ignorerer dem, der gør. Lad mig være ligefrem om begge lister.

Hvad der virkelig betyder noget

Hvem der kan bygge og vedligeholde den. Den enkeltstående største faktor er ikke teknologien — det er menneskene. Den bedste stak for dig er den, dit team (eller den partner, du hyrer) faktisk kan arbejde i, flydende, i dag. En ”perfekt” stak, som kun én sjælden specialist forstår, er et dårligere valg end en kedelig, som enhver kompetent udvikler kan overtage. Rekruttering og kontinuitet slår teoretisk elegance hver gang.

Hvor hurtigt du kan ændre ting. Tidligt vil du konstant tage fejl om dit produkt. Stakkens egentlige opgave er at gøre det billigt at skifte mening. Modne, veldokumenterede værktøjer med store fællesskaber lader dig bevæge dig hurtigt, fordi svarene på dine problemer allerede findes. Knivskarpt nye værktøjer gør dig til den, der opdager fejlene.

Om du kan rekruttere til den. Vælg noget obskurt, og du binder din fremtid til den, der byggede det. Vælg noget almindeligt og kedeligt, og du kan altid finde den næste udvikler, det næste bureau, den næste person til at overtage. Kedeligt er en fordel, når din forretning afhænger af det.

Hvad der betyder langt mindre, end folk siger

Rå ydeevne og ”skala”. Du har ikke et skaleringsproblem. Du har et ingen-bruger-det-endnu-problem, hvilket er det modsatte problem. Arkitekturer designet til millioner af brugere vil sinke dig, når du har elleve. De berømte virksomheder, du efterligner, byggede den simple version først og byggede om senere, finansieret af succes. Det bør du også.

Hvilket bestemt framework der ”vinder” i år. Frameworks stiger og falder i en modecyklus, der næsten intet har at gøre med, om de bygger din fakturerings-SaaS godt. Enhver af de etablerede, bredt anvendte muligheder klarer opgaven. Trenden er støj; vælg fra den kedelige, populære midte og kom videre.

Hvorfor ”kedelig” teknologi som regel vinder

Der findes en stille visdom blandt erfarne byggere, som nytilkomne finder skuffende: den bedste teknologi til en ny forretning er som regel den kedelige, gennemprøvede, lidt umoderne slags. Ikke fordi nye værktøjer er dårlige, men fordi hvert valg, du træffer, bruger af et begrænset budget af nyhed — antallet af ukendte, ikke-understøttede, overraskende ting, dit lille team kan håndtere på én gang.

Brug det budget på det, der gør din forretning særlig — selve produktet, indsigten, kun du har. Brug det ikke på en database, ingen har hørt om, bare for at føle dig moderne. En kedelig, moden stak betyder, at problemer er løst før, dokumentation findes, rekruttering er let, og værktøjet forsvinder ikke næste år, når dets eneste vedligeholder mister interessen. Kedeligt lader dig lægge al din begejstring der, hvor den betaler sig: hos kunden.

Det er også her, AI ændrer billedet en smule — og ikke på den måde, hypen antyder. AI-kodningsassistenter er dramatisk bedre til kedelig, populær teknologi, fordi de blev trænet på et årtis offentlige svar om den. Vælg en etableret stak, og dit team (og dine værktøjer) får hurtigere hjælp gratis. Vælg noget eksotisk, og du er på egen hånd præcis når du har mindst råd til det.

En beslutningsmetode, du faktisk kan bruge

Nok principper. Her er en konkret måde at nå frem til en beslutning, uanset om du vælger selv, briefer en freelancer eller vurderer, hvad et bureau foreslår. Intet af det kræver, at du skriver kode — kun at du spørger om de rigtige ting og vejer svarene.

1. 1
   Tag udgangspunkt i teamet, ikke teknologien

   Spørg: hvem bygger og vedligeholder det her de næste to år? Hvad de allerede kan godt, er din stærke standard. At skifte stak for at jagte en trend slår sjældent flydende kunnen.
2. 2
   Standarden er etableret og gennemprøvet

   Vælg fra den populære, veldokumenterede midte af hvert lag. Hvis du ikke hurtigt kan finde guides, jobs og store fællesskaber for et værktøj, behandl det som en advarsel, ikke en fordel.
3. 3
   Optimer for forandring, ikke skala

   Foretræk valget, der gør det billigt og hurtigt at redigere dit produkt. Du vil tage fejl om produktet gang på gang — stakkens opgave er at gøre det overlevbart at tage fejl.
4. 4
   Hold arkitekturen så simpel, den kan være

   Én database. Én backend. Én frontend. Ingen mikrotjenester, intet smart distribueret noget, før et reelt, målt problem tvinger din hånd. Enkelhed er målet, ikke kompromiset.
5. 5
   Skriv ned, hvorfor du valgte den

   Ét afsnit: hvem bygger den, hvad du valgte, og hvad der skulle ændres, for at du genovervejer. Den note sparer dig for at tage beslutningen op igen, hver gang nogen læser en skarp holdning.

Følger du intet andet, så følg trin et og fire. Byg med de mennesker, du har, på den simpleste arkitektur, der virker. Den kombination undgår stille de to fejltyper, der sænker de fleste første SaaS-produkter: ingen, der kan vedligeholde den, og et system, der er for kompliceret til sin egen størrelse.

Spørgsmål til den, der foreslår en stak

De fleste stiftere vælger ikke stakken alene — en udvikler, et bureau eller en CTO-ven foreslår en. Du behøver ikke verificere teknologien selv. Du skal stille en håndfuld spørgsmål og lytte til, hvordan de svarer. Selvsikre svar i klart sprog er et godt tegn. Defensiv jargon er det ikke.

• ”Hvorfor det her, og ikke den kedelige populære mulighed?” — et godt svar handler om dine specifikke behov, ikke om, hvad der er trendy.
• ”Hvis du blev kørt over af en bus, hvor let kunne en anden så overtage det her?” — svaret afslører, hvor sjældent og risikabelt valget er.
• ”Hvad er den simpleste version af denne arkitektur, der stadig virker?” — hold øje med, om de griber efter enkelhed eller kompleksitet.
• ”Hvor let bliver det at rekruttere den næste udvikler til det her?” — almindelige kompetencer betyder et sundt marked; eksotiske betyder afhængighed.
• ”Hvad sker der, når vi skal ændre en kernefunktion om tre måneder?” — du vil høre, at forandring er billig, ikke frygtet.

Almindelige fælder, der ligner gode idéer

Nogle få mønstre dukker op så ofte, at de er værd at navngive, for hvert af dem føles ansvarligt i øjeblikket og koster dig dyrt senere.

At bygge til en skala, du ikke har. Trangen til at ”gøre det ordentligt” får stiftere til at arkitekte til millioner af brugere, før de har ti. Hver bid af den fremtidssikring er kompleksitet, du betaler for nu, i tid og penge, for at løse et problem, der måske aldrig opstår. Byg til de næste hundrede brugere. Omarkitektér, når vækst gør det nødvendigt — og lad det være et lykkeligt problem.

At jagte det nyeste. Et skinnende framework, der udkom sidste måned, har ingen track record, tynd dokumentation og et lillebitte fællesskab. Du vil bruge dine nætter på at fejlsøge værktøjet i stedet for at bygge dit produkt. Lad andre være de tidlige brugere; du har en forretning at få i mål.

At outsource til den billigste, på hvad end vedkommende foretrækker. Det laveste bud kommer ofte med en obskur stak, kun det ene team kan. Den dag I skilles, bliver dit produkt en ø, ingen anden kan nå. Billigt i starten, ruinerende senere. Insistér på etableret, rekrutterbar teknologi, selv når du outsourcer — især når du outsourcer.

Hvornår det faktisk er tid til at genoverveje din stak

Intet af dette betyder ”skift aldrig”. Det betyder skift af reelle grunde, målte, ikke indbildte. Du ved, det virkelig er tid til at videreudvikle din stak, når konkrete signaler dukker op — ikke når et blogindlæg gør dig ængstelig.

Læg mærke til mønstret: reelle grunde handler om målt smerte i din faktiske forretning. Falske grunde handler om mode, sammenligning og rastløshed. Når et reelt signal endelig dukker op, skifter du én bid ad gangen — ikke hele stakken i en heroisk omskrivning, der sætter alt i stå i seks måneder. Evolution, ikke revolution.

Almindelige spørgsmål