Opas

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.

Have a nice dayHave a nice day11 min lukuaika
Teknologiapinon valinta ensimmäiseen SaaS-tuotteeseesi: perustajan rehellinen opas

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.
tämän kerron jokaiselle perustajalle ennen kuin aloitamme

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.

Selkeä, ystävällinen neljän kerroksen kaavio ohjelmistopinosta — frontend, backend, tietokanta, infrastruktuuri — piirrettynä pinottuina vaakalaattoina pienine ikoneineen, rauhallisessa toimituksellisessa litteässä kuvitustyylissä vaalealla taustalla
Jokainen SaaS on jokin versio näistä neljästä kerroksesta. Verkon kiistat ovat enimmäkseen siitä, mitä laatan merkkiä käyttää.

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.

Luotettava, hieman vanhanaikainen alasin tai tukeva työpenkki lämpimässä valossa, vieressään näyttävä mutta hauras neonvekotin, joka välkkyy — visuaalinen vertauskuva tylsistä koetelluista työkaluista vastaan trendikkäät hauraat, toimituksellinen litteä tyyli
Jännittävä työkalu on hauska, kunnes se hajoaa keskellä yötä eikä ole ketään keneltä kysyä. Tylsillä työkaluilla on käyttöohje.

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.

  1. 1
    Aloita tiimistä, älä teknologiasta
    Kysy: 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.
  2. 2
    Oletuksena valtavirta ja koeteltu
    Valitse 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.
  3. 3
    Optimoi muutosta varten, älä skaalaa
    Suosi valintaa, joka tekee tuotteesi muokkaamisesta halpaa ja nopeaa. Olet väärässä tuotteestasi toistuvasti — pinon tehtävä on tehdä väärässä olemisesta selviytyvää.
  4. 4
    Pidä arkkitehtuuri niin yksinkertaisena kuin se voi olla
    Yksi 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.
  5. 5
    Kirjoita ylös, miksi valitsit sen
    Yksi 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ä.
Rauhallinen keskustelu pöydän ääressä ei-teknisen perustajan ja kehittäjän välillä, perustaja pitelee lyhyttä kysymyslistaa, molemmat rentoina ja yhteistyöhaluisina, lämmin luonnonvalo, toimituksellinen litteä kuvitus
Sinun ei tarvitse tietää vastauksia — sinun täytyy kysyä kysymykset ja huomata, miten niihin vastataan.

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.
testi, joka nappaa useimmat huonot valinnat

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.

SignaaliAito syy muuttaa?Mitä tehdä
Sovellus on mitattavasti hidas oikeille käyttäjilleKylläMittaa ensin, korjaa tietty pullonkaula
Ominaisuuksien lisääminen hidastuu jatkuvastiKylläYksinkertaista tai refaktoroi kivulias osa
Et pysty rekrytoimaan ketään, joka osaa senKylläSuunnittele harkittu siirtymä yleisiin työkaluihin
Kilpailija käyttää trendikkäämpää pinoaEiSivuuta — heidän pinonsa ei ole heidän etunsa
Uusi kehys julkaistiin ja näyttää siistiltäEiLisää kirjanmerkkeihin, jatka julkaisemista
Insinööriä yksinkertaisesti kyllästyttääEiKäsittele työilmapiiriä, älä arkkitehtuuria
Signaalit, että ensimmäisestä pinostasi ollaan aidosti kasvamassa yli — vastaan kohina, joka vain tuntuu kiireelliseltä.

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 ohjelmistoa

Yleisiä kysymyksiä

Onko olemassa yhtä parasta teknologiapinoa SaaS-startupille?
Ei, ja kuka tahansa, joka sanoo kyllä tuntematta liiketoimintaasi, arvaa. Paras pino on se, jonka tiimisi osaa rakentaa ja ylläpitää sujuvasti, tehtynä valtavirran, hyvin tuetuista työkaluista, yksinkertaisimmalla toimivalla arkkitehtuurilla. Useimmille ensimmäisille SaaS-tuotteille se tarkoittaa yhtä suosittua frontend-kehystä, yhtä backendia, yhtä relaatiotietokantaa kuten Postgres ja vakiopilvihostingia — mutta tietyillä nimillä on paljon vähemmän väliä kuin periaatteilla.
Pitäisikö minun käyttää uusinta, modernein kehystä?
Yleensä ei ensimmäiseen tuotteeseesi. Uusilla kehyksillä on ohut dokumentaatio, pienet yhteisöt ja löytämättömät bugit, mikä tarkoittaa, että vietät yösi korjaten työkalua sen sijaan, että rakentaisit liiketoimintaasi. Valitse jotain koeteltua ja hieman tylsää; liikut nopeammin ja löydät apua — ihmis- ja tekoäly — paljon helpommin. Anna muiden olla varhaiskäyttäjiä.
Tarvitsenko mikropalvelut tai ”skaalautuvan” arkkitehtuurin ensimmäisestä päivästä?
Lähes varmasti et. Mikropalvelut ja monimutkaiset skaalautuvat kokoonpanot ratkaisevat suuren skaalan ongelmia, joita sinulla ei vielä ole, lisäten samalla monimutkaisuutta, johon pienellä tiimillä ei ole varaa. Aloita yhdellä yksinkertaisella backendilla ja tietokannalla. Yritykset, joita ihailet, rakensivat ensin yksinkertaisen version ja uudelleenarkkitehtuuroivat myöhemmin, menestyksensä rahoittamana. Niin pitäisi sinunkin.
Miten arvioin pinoa, jos en ole tekninen?
Et arvioi teknologiaa suoraan — arvioit vastauksia. Kysy ehdottajalta, miksi hän valitsi sen, kuinka helposti joku muu voisi ottaa sen haltuun, kuinka yksinkertainen se voi olla ja kuinka helppoa siihen on rekrytoida. Kuuntele selkokielisiä, kompromissitietoisia vastauksia. Itsevarma jargon, joka väistää kysymyksesi, on varoitusmerkki; rehellinen ”riippuu” on rauhoittavaa.
Entä jos valitsen väärin — olenko jumissa ikuisesti?
Et. Ohjelmisto ei ole perustus, jonka valat kerran; se on enemmän kuin keittiö, jonka voit remontoida kesken kokkaamisen. Pinoja kirjoitetaan osittain uudelleen tuotteiden kasvaessa, ja se on normaalia, ei epäonnistumista. Kunhan valitsit valtavirran, rekrytoitavia työkaluja ja pidit asiat yksinkertaisina, suunnan muuttaminen myöhemmin on hallittavissa oleva, pala kerrallaan -työ — ei katastrofi.
Have a nice day
Have a nice day
Toimitus

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.

Sopivat palvelut