Teknologiapinon valinta ensimmäiseen SaaS-tuotteeseesi: perustajan rehellinen opas
Suurin osa pinokiistoista on uskonsotia insinöörien välillä, jotka eivät ikinä käytä tuotettasi. Tämä on rauhallisempi versio: miten ei-tekninen perustaja valitsee teknologiapinon, joka vie SaaSin maaliin maksavine asiakkaineen ilman, että koko yritys lyödään yhden trendin varaan.

Kysy kymmeneltä insinööriltä, mitä teknologiapinoa pitäisi käyttää ensimmäiseen SaaSiisi, ja saat viisitoista vastausta, joista kolme esitetään uskonnon varmuudella. Useimmat näistä vastauksista ovat oikein — vastauksen antajan kannalta. Mikään niistä ei koske sinua, kassavaraasi tai asiakkaita, joita et ole vielä saanut allekirjoittamaan. Jos olet perustaja, joka tuijottaa tätä päätöstä ja voi hieman pahoin, tässä se mitä kukaan ei sano ääneen: pinolla on paljon vähemmän väliä kuin sinulle on uskoteltu, eivätkä ne harvat tavat, joilla sillä on väliä, ole niitä, joista verkossa kiistellään.
Olen auttanut melkoisen joukon ensikertalaisia perustajia diaesityksestä tuotteeseen, josta oikeat ihmiset maksavat. Lähes kukaan heistä ei ollut tekninen. Lähes kaikki saapuivat omaksuttuaan pelottavan määrän pinotarustoa — että he tarvitsivat mikropalveluita, että jokin kehys oli ”kuollut”, että väärä valinta tuhoaisi heidät. Ja melkein joka kerta pino osoittautui yhdeksi sen vuoden vähämerkityksisimmistä päätöksistä. Projektit tappoi laajuus, epäselvä omistajuus ja väärän asian rakentaminen kauniisti. Ei koskaan kehys.
Tämä on siis opas, jonka annan noille perustajille ennen kuin kirjoitamme riviäkään koodia. Se ei käske käyttämään yhtä tiettyä pinoa, koska kuka tahansa, joka lupaa sellaista tuntematta liiketoimintaasi, on myymässä jotain. Sen sijaan se antaa sinulle ajattelutavan — niin että valitsit mitä tahansa tai tiimisi ehdotti mitä tahansa, voit tarkistaa sen järkevästi kuten aikuinen sen sijaan, että nyökkäilisit hermostuneesti mukana.
Miksi tämä päätös tuntuu vaikeammalta kuin se on
Pinokysymys tuntuu valtavalta, koska se on ensimmäinen peruuttamattomalta kuulostava valinta, jonka teet, ja se on kääritty kieleen, jota et puhu. Sanoja kuten Postgres, React, Kubernetes, serverless heitellään ikään kuin niiden välillä valitseminen olisi kuin rakennuksen perustusten valitsemista — valitse väärin ja koko juttu romahtaa.
Mutta ohjelmisto ei ole rakennus. Se on paljon lähempänä keittiötä, jonka voit remontoida kesken kokkaamisen. Menestyvät yritykset kirjoittavat osia pinostaan jatkuvasti uudelleen; tuotteen versio, joka löytää ensimmäiset sata asiakastaan, ei lähes koskaan ole se versio, joka palvelee ensimmäistä satatuhatta. Ensimmäisen pinosi tavoite ei ole kestää ikuisesti. Sen tavoite on antaa sinun rakentaa, muuttaa ja julkaista riittävän nopeasti, jotta opit, haluaako tätä kukaan ollenkaan. Se on aivan eri — ja paljon matalampi — rima kuin ”täydellinen seuraavaksi vuosikymmeneksi”.
“Ensimmäisen pinosi ei tarvitse olla se, jolla skaalaat. Sen täytyy olla se, jonka avulla selvität, onko skaalautuminen edes ongelma, joka kannattaa olla.”
Kun hyväksyt tämän, paine laskee puoleen. Et enää yritä ennustaa tulevaisuutta. Yrität tehdä järkevän, peruutettavan vedon, joka vie sinut toimivaan tuotteeseen ja maksaviin käyttäjiin. Ja järkevät vedot ovat jotain, mitä ei-tekninen perustaja pystyy aivan hyvin arvioimaan.
Mitä ”pino” oikeastaan on, selkokielellä
Ennen kuin päätät mitään, sanan avaaminen auttaa. Teknologiapino on vain kokoelma työkaluja, joilla ohjelmistosi rakennetaan ja sitä ajetaan. Voit ajatella sitä neljänä kerroksena, eikä sinun tarvitse ymmärtää yhtäkään niistä syvällisesti — sinun täytyy vain tietää, että ne ovat olemassa.
- Frontend — se mitä käyttäjät näkevät ja klikkaavat selaimessaan tai sovelluksessaan. Tämä on osa, jonka perusteella kaikki sinua arvostelevat.
- Backend — palvelimella pyörivä logiikka ja säännöt: kuka saa tehdä mitä, mitä tapahtuu kun he tekevät, miten raha liikkuu.
- Tietokanta — missä tietosi oikeasti asuvat: käyttäjät, tilaukset, tilaukset, kaikki minkä menettäminen tuhoaisi sinut.
- Infrastruktuuri — palvelimet ja palvelut, jotka pitävät kaiken yllä olevan verkossa, varmuuskopioituna ja tavoitettavissa kello 3 yöllä.
Kun joku sanoo ”käytämme modernia JavaScript-pinoa” tai ”Rails Postgresin päällä”, hän kuvaa valintoja näissä neljässä kerroksessa. Siinä kaikki. Jokainen SaaS, kaksihenkisestä sivuprojektista pörssiyhtiöön, on jokin versio näistä neljästä asiasta pinottuna. Mahtipontiset arkkitehtuurikaaviot ovat vain tätä, piirrettynä useammilla laatikoilla.

Asiat, joilla oikeasti on väliä (ja ne, joilla ei)
Tässä useimmat pinoneuvot menevät pieleen: ne optimoivat asioita, jotka eivät vaikuta kahteen ensimmäiseen vuoteesi, ja sivuuttavat ne, jotka vaikuttavat. Olen suora molemmista listoista.
Mikä oikeasti merkitsee
Kuka osaa rakentaa ja ylläpitää sitä. Suurin yksittäinen tekijä ei ole teknologia — vaan ihmiset. Paras pino sinulle on se, jossa tiimisi (tai palkkaamasi kumppani) osaa oikeasti työskennellä sujuvasti, tänään. ”Täydellinen” pino, jonka ymmärtää vain yksi harvinainen erikoisosaaja, on huonompi valinta kuin tylsä, jonka kuka tahansa pätevä kehittäjä voi omaksua. Rekrytointi ja jatkuvuus voittavat teoreettisen tyylikkyyden joka kerta.
Kuinka nopeasti voit muuttaa asioita. Alussa olet jatkuvasti väärässä tuotteestasi. Pinon todellinen tehtävä on tehdä mielenmuutoksesta halpaa. Kypsät, hyvin dokumentoidut työkalut suurine yhteisöineen antavat sinun liikkua nopeasti, koska vastaukset ongelmiisi ovat jo olemassa. Veitsenterävän uudet työkalut tekevät sinusta sen, joka löytää bugit.
Pystytkö rekrytoimaan sille. Valitse jotain hämärää ja sidot tulevaisuutesi siihen, joka sen rakensi. Valitse jotain yleistä ja tylsää ja löydät aina seuraavan kehittäjän, seuraavan toimiston, seuraavan henkilön ottamaan vastuun. Tylsyys on ominaisuus, kun liiketoimintasi riippuu siitä.
Mikä merkitsee paljon vähemmän kuin sanotaan
Raaka suorituskyky ja ”skaala”. Sinulla ei ole skaalaongelmaa. Sinulla on kukaan-ei-käytä-sitä-vielä-ongelma, joka on päinvastainen ongelma. Miljoonille käyttäjille suunnitellut arkkitehtuurit hidastavat sinua, kun sinulla on yksitoista. Kuuluisat yritykset, joita matkit, rakensivat ensin yksinkertaisen version ja rakensivat uudelleen myöhemmin, menestyksen rahoittamana. Niin pitäisi sinunkin.
Mikä tietty kehys ”voittaa” tänä vuonna. Kehykset nousevat ja laskevat muotisyklissä, jolla ei ole juuri mitään tekemistä sen kanssa, rakentavatko ne laskutus-SaaSisi hyvin. Mikä tahansa valtavirran, laajasti käytetyistä vaihtoehdoista hoitaa homman. Trendi on kohinaa; valitse tylsästä, suositusta keskivaihtoehdosta ja jatka eteenpäin.
Miksi ”tylsä” teknologia yleensä voittaa
Kokeneiden rakentajien keskuudessa vallitsee hiljainen viisaus, joka tulokkaista tuntuu pettymykseltä: paras teknologia uudelle liiketoiminnalle on yleensä tylsä, koeteltu, hieman epämuodikas laji. Ei siksi, että uudet työkalut olisivat huonoja, vaan koska jokainen valintasi kuluttaa rajallista uutuusbudjettia — niiden tuntemattomien, tukemattomien, yllättävien asioiden määrää, jotka pieni tiimisi pystyy käsittelemään kerralla.
Käytä se budjetti siihen, mikä tekee liiketoiminnastasi erityisen — itse tuotteeseen, oivallukseen, joka on vain sinulla. Älä käytä sitä tietokantaan, josta kukaan ei ole kuullut, vain tunteaksesi olosi moderniksi. Tylsä, kypsä pino tarkoittaa, että ongelmat on ratkaistu ennenkin, dokumentaatio on olemassa, rekrytointi on helppoa eikä työkalu katoa ensi vuonna, kun sen ainoa ylläpitäjä menettää kiinnostuksensa. Tylsyys antaa sinun suunnata kaiken innostuksesi sinne, missä se palkitsee: asiakkaaseen.

Tässä myös tekoäly muuttaa kuvaa hieman — eikä sillä tavalla kuin hype antaa ymmärtää. Tekoälyn koodausavustajat ovat dramaattisesti parempia tylsissä, suosituissa teknologioissa, koska ne koulutettiin vuosikymmenen julkisilla vastauksilla niistä. Valitse valtavirran pino, niin tiimisi (ja työkalusi) saavat nopeampaa apua ilmaiseksi. Valitse jotain eksoottista, niin olet omillasi juuri silloin, kun sinulla on siihen vähiten varaa.
Päätösmenetelmä, jota voit oikeasti käyttää
Tarpeeksi periaatteita. Tässä konkreettinen tapa päästä päätökseen, valitsitpa itse, briiffaisitpa freelanceria tai arvioisitpa, mitä toimisto ehdottaa. Mikään siitä ei vaadi sinua kirjoittamaan koodia — vain kysymään oikeat asiat ja punnitsemaan vastaukset.
- 1Aloita tiimistä, älä teknologiastaKysy: kuka rakentaa ja ylläpitää tätä seuraavat kaksi vuotta? Mitä he jo osaavat hyvin, on vahva oletuksesi. Pinon vaihtaminen trendin perässä voittaa harvoin sujuvuuden.
- 2Oletuksena valtavirta ja koeteltuValitse kunkin kerroksen suositusta, hyvin dokumentoidusta keskivaihtoehdosta. Jos et löydä nopeasti opetusvideoita, työpaikkoja ja suuria yhteisöjä työkalulle, pidä sitä varoituksena, ei ominaisuutena.
- 3Optimoi muutosta varten, älä skaalaaSuosi valintaa, joka tekee tuotteesi muokkaamisesta halpaa ja nopeaa. Olet väärässä tuotteestasi toistuvasti — pinon tehtävä on tehdä väärässä olemisesta selviytyvää.
- 4Pidä arkkitehtuuri niin yksinkertaisena kuin se voi ollaYksi tietokanta. Yksi backend. Yksi frontend. Ei mikropalveluita, ei nokkelaa hajautettua mitään, ennen kuin todellinen, mitattu ongelma pakottaa kätesi. Yksinkertaisuus on tavoite, ei kompromissi.
- 5Kirjoita ylös, miksi valitsit senYksi kappale: kuka rakentaa sen, mitä valitsit ja minkä pitäisi muuttua, jotta harkitsisit uudelleen. Tämä muistiinpano säästää sinut päätöksen uudelleenkäsittelyltä joka kerta, kun joku lukee jonkin kärkkään mielipiteen.
Jos et seuraa mitään muuta, seuraa vaiheita yksi ja neljä. Rakenna niiden ihmisten kanssa, joita sinulla on, yksinkertaisimmalla toimivalla arkkitehtuurilla. Tämä yhdistelmä välttää hiljaa kaksi epäonnistumistapaa, jotka upottavat useimmat ensimmäiset SaaS-tuotteet: kukaan ei osaa ylläpitää sitä, ja järjestelmä on liian monimutkainen kokoonsa nähden.
Kysymyksiä jokaiselle, joka ehdottaa pinoa
Useimmat perustajat eivät valitse pinoa yksin — kehittäjä, toimisto tai CTO-ystävä ehdottaa sellaista. Sinun ei tarvitse itse varmistaa teknologiaa. Sinun täytyy kysyä kourallinen kysymyksiä ja kuunnella, miten he vastaavat. Itsevarmat, selkokieliset vastaukset ovat hyvä merkki. Puolusteleva jargon ei ole.
- ”Miksi tämä eikä tylsä suosittu vaihtoehto?” — hyvä vastaus koskee erityistarpeitasi, ei sitä, mikä on trendikästä.
- ”Jos jäisit bussin alle, kuinka helposti joku muu voisi ottaa tämän haltuun?” — vastaus paljastaa, kuinka harvinainen ja riskialtis valinta on.
- ”Mikä on tämän arkkitehtuurin yksinkertaisin versio, joka silti toimii?” — tarkkaile, tarttuvatko he yksinkertaisuuteen vai monimutkaisuuteen.
- ”Kuinka helppoa on rekrytoida seuraava kehittäjä tähän?” — yleiset taidot tarkoittavat tervettä markkinaa; eksoottiset tarkoittavat riippuvuutta.
- ”Mitä tapahtuu, kun meidän pitää muuttaa ydinominaisuutta kolmen kuukauden päästä?” — haluat kuulla, että muutos on halpaa, ei pelättyä.

Yleisiä ansoja, jotka näyttävät hyviltä ideoilta
Muutamia kaavoja tulee vastaan niin usein, että ne kannattaa nimetä, koska jokainen tuntuu sillä hetkellä vastuulliselta ja maksaa sinulle kalliisti myöhemmin.
Rakentaminen skaalalle, jota sinulla ei ole. Halu ”tehdä se kunnolla” johtaa perustajat suunnittelemaan miljoonille käyttäjille ennen kuin heillä on kymmentä. Jokainen pala tuosta tulevaisuuden varmistelusta on monimutkaisuutta, jonka maksat nyt, ajassa ja rahassa, ratkaistaksesi ongelman, joka ei ehkä koskaan saavu. Rakenna seuraavalle sadalle käyttäjälle. Uudelleenarkkitehtuuroi, kun kasvu tekee siitä välttämätöntä — ja anna sen olla onnellinen ongelma.
Uusimman jahtaaminen. Viime kuussa julkaistulla kiiltävällä kehyksellä ei ole näyttöjä, on ohut dokumentaatio ja pieni yhteisö. Vietät yösi virheitä jäljittäen työkalussa sen sijaan, että rakentaisit tuotettasi. Anna muiden olla varhaiskäyttäjiä; sinulla on liiketoiminta julkaistavana.
Ulkoistaminen halvimmalle, sillä mitä hän suosii. Alin tarjous tulee usein hämärän pinon kanssa, jonka vain tuo yksi tiimi tuntee. Sinä päivänä, kun eronne, tuotteestasi tulee saari, jolle kukaan muu ei pääse. Halpa alussa, tuhoisa myöhemmin. Vaadi valtavirran, rekrytoitavaa teknologiaa silloinkin, kun ulkoistat — erityisesti kun ulkoistat.
“Oikea pino on se, jonka vieras voisi ottaa haltuun ja jatkaa. Jos vain sen rakentaja ymmärtää sitä, et omista tuotetta — omistat riippuvuuden.”
Milloin on oikeasti aika tarkastella pinoa uudelleen
Mikään tästä ei tarkoita ”älä koskaan muuta”. Se tarkoittaa: muuta oikeista syistä, mitattuna, ei kuviteltuna. Tiedät, että on aidosti aika kehittää pinoasi, kun konkreettiset signaalit ilmaantuvat — ei kun jokin blogikirjoitus tekee sinut ahdistuneeksi.
| Signaali | Aito syy muuttaa? | Mitä tehdä |
|---|---|---|
| Sovellus on mitattavasti hidas oikeille käyttäjille | Kyllä | Mittaa ensin, korjaa tietty pullonkaula |
| Ominaisuuksien lisääminen hidastuu jatkuvasti | Kyllä | Yksinkertaista tai refaktoroi kivulias osa |
| Et pysty rekrytoimaan ketään, joka osaa sen | Kyllä | Suunnittele harkittu siirtymä yleisiin työkaluihin |
| Kilpailija käyttää trendikkäämpää pinoa | Ei | Sivuuta — heidän pinonsa ei ole heidän etunsa |
| Uusi kehys julkaistiin ja näyttää siistiltä | Ei | Lisää kirjanmerkkeihin, jatka julkaisemista |
| Insinööriä yksinkertaisesti kyllästyttää | Ei | Käsittele työilmapiiriä, älä arkkitehtuuria |
Huomaa kaava: aidot syyt koskevat mitattua kipua oikeassa liiketoiminnassasi. Valheelliset syyt koskevat muotia, vertailua ja levottomuutta. Kun aito signaali ilmaantuu, muutat yhden palan kerrallaan — et koko pinoa sankarillisessa uudelleenkirjoituksessa, joka pysäyttää kaiken kuudeksi kuukaudeksi. Evoluutiota, ei vallankumousta.
Haluatko toisen mielipiteen ennen kuin sitoudut?
Pinon valinta — tai jonkun ehdottaman järkevä tarkistus — on yhden keskustelun ongelma paljon useammin kuin perustajat odottavat. Katsomme mielellämme ideaasi ja kerromme rehellisesti, mitä kannattaa rakentaa, miten ja mikä pidetään yksinkertaisena.
Katso miten rakennamme ohjelmistoaYleisiä kysymyksiä
Onko olemassa yhtä parasta teknologiapinoa SaaS-startupille?
Pitäisikö minun käyttää uusinta, modernein kehystä?
Tarvitsenko mikropalvelut tai ”skaalautuvan” arkkitehtuurin ensimmäisestä päivästä?
Miten arvioin pinoa, jos en ole tekninen?
Entä jos valitsen väärin — olenko jumissa ikuisesti?

Have a nice day on ohjelmistostudio, joka auttaa pieniä ja keskisuuria yrityksiä digitalisoitumaan — automaatiota, tekoälyä ja räätälöityjä ohjelmistoja, jotka toimivat arjessa, eivät vain kalvoilla.