B2B SaaS MVP: kuus otsust, mis hiljem kalliks lähevad

Miks kuus otsust loevad rohkem kui funktsioonide nimekiri

B2B SaaS-is on kliendile nähtavad funktsioonid ning otsused, mis mõjutavad seda, kui palju tööd hilisemad muudatused nõuavad.

Rentniku ehk kliendiettevõtte andmete eraldus, rollimudel ja arvelduse loogika puudutavad mitut tooteosa. Nende hilisem muutmine võib nõuda andmete ja mitme mooduli ümbertegemist. Selles artiklis on kuus sellist otsust ja kontrollküsimused, mida enne funktsioonide lisamist läbi mõelda.

Töö ulatuse ja ajakava poolelt vaata kõigepealt artiklit MVP arendus: mida kolme nädalaga päriselt valmis saab. Seal on kirjas, mis üldse esimesse versiooni mahub. Siin on kuus otsust, millele esimeses versioonis mõelda.

Kuus otsust ühe tabelina

Iga rida on otsus, mille hilisem muutmine võib puudutada mitut tooteosa. Viimane veerg kirjeldab küsimust, mida enne arendust läbi mõelda.

1. Rentniku andmeeraldus

See on otsus, mille viga ei ole nähtav enne, kui mõni klient seda märkab. Kolm levinud mudelit:

• Ühine andmebaas ja rentniku veerg igas tabelis. Kõige odavam alustada ja kõige lihtsam hallata. Nõuab, et iga päring oleks filtreeritud, sh need, mille keegi kirjutab aasta pärast.
• Skeem rentniku kohta. Eraldab andmed tugevamalt, aga migratsioonid tuleb käivitada iga skeemi peal ja see muutub kümnete klientide juures tülikaks.
• Andmebaas rentniku kohta. Tugevaim eraldus, kalleim haldus ja mõttekas siis, kui klient nõuab seda lepinguliselt.

Kui alustad esimese mudeliga, ära jäta eraldust rakenduse koodi hooleks. PostgreSQL-is saab rakendada reataseme turvareegleid, mis piiravad rakenduse andmebaasirolli päringuid:

ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
ALTER TABLE invoices FORCE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON invoices
  USING (tenant_id = current_setting('app.tenant_id')::uuid);

Rakendus seab iga päringu alguses oma tehingu sees SET LOCAL app.tenant_id. Kasuta andmebaasirolli, mis ei ole superkasutaja ega oma BYPASSRLS-õigust. Rentniku tunnuse määrab server kontrollitud kasutaja ja kliendiettevõtte seose põhjal; kliendi saadetud tunnust ei tohi usaldada. Reeglite käitumine ja erandid on kirjas PostgreSQL-i dokumentatsioonis.

2. Rollid ja õigused

Alguses võib rollide loend olla lühike: kasutaja ja administraator. Probleem algab hetkest, kui esimene klient ütleb, et tema raamatupidaja peaks nägema arveid, aga mitte seadeid, ja müügijuht peaks nägema oma piirkonda. Kui rollid on koodis if (user.role === "admin") kujul laiali, tähendab see muudatust mitmes vaates.

Kirjelda õigused eraldi ja koonda kontroll serverisse. Iga roll ühendab vajalikke õigusi; päring kontrollib õigust, mitte ainult seda, kas menüükirje on nähtav.

1. Kirjelda õigused tegudena

   „Näeb arveid“, „muudab hindu“, „kustutab kirjeid“. Mitte „on administraator“. Tegude loend on lühike ja seda saab klient ise täpsustada.

2. Kontrolli igas serveripoolses sisenemispunktis

   Menüü peitmine ei ole õiguste kontroll. Kui server tagastab kaitstud andmed õigusi kontrollimata, ei kaitse menüü peitmine neid andmeid.

3. Logi muudatused, mis puudutavad raha ja juurdepääsu

   Kes muutis hinda, kes andis õiguse, kes kustutas. Hoia logis vajalik sündmus ja piira ligipääs logile.

Isikuandmete osas tasub lugeda Andmekaitse Inspektsiooni lehte andmeturbe kohta: logi, mida sa pead, on turvameede, aga logi, mida sa ei vaja, on uus risk.

3. Arveldus ja tellimuse olek

Arveldus on koht, kus tehniline otsus ja äriloogika lõikuvad. Vale otsus ei ole „kas kasutada makseteenust“, vaid „kus asub tõde selle kohta, kas kliendil on juurdepääs“.

Kolm asja, mis tuleb paika panna enne esimest tasulist klienti:

• Üks tõeallikas. Tellimuse olek elab ühes kohas ja rakendus loeb seda, mitte ei tuleta seda mitmest väljast. Kui olek on kahes kohas, on need kunagi erinevad.
• Korratav sündmuste töötlemine. Makseteenuse veebikonks võib sama sündmuse saata rohkem kui korra. Iga sündmuse töötlemine peab olema idempotentne: sama sündmuse teine kord ei tohi tekitada teist arvet ega teist juurdepääsu.
• Ebaõnnestunud makse. Stripe'i tellimuste dokumentatsioon ütleb otse, et korduskatsed, meeldetuletused ja olekusiirded on nende poolt kaetud. See ei tähenda, et sinu tootes ei pea olema vastust küsimusele, mida teeb kasutaja siis, kui juurdepääs on peatatud ja andmed on alles.

Eesti kontekstis lisandub maksude küsimus. Kui klient on teises riigis, ei ole arve lihtsalt summa ja kuupäev. See on teema, mille jaoks tasub enne esimest välismaist klienti küsida raamatupidajalt nõu, mitte leiutada reegleid koodis.

4. Identiteet ja kutsumised

B2B tootes kuulub kasutaja kliendiettevõtte ehk rentniku alla, ta lisatakse kutsega ja tema juurdepääs eemaldatakse siis, kui ta lahkub.

Kolm asja, mida kasutajamudelis läbi mõelda:

• Kutsevoog, kus administraator lisab inimese e-posti ja inimene loob ise parooli. Ilma selleta luuakse kasutajad käsitsi ja paroolid võivad liikuda e-kirjaga.
• Konto deaktiveerimine. Hoia vajalik auditilogi alles ainult asjakohase töötlemise aluse ja säilitustähtaja piires.
• Ettevõtte domeeni seos. Kui kliendiettevõte kinnitab domeeni, saab sisenemise siduda sellega ilma käsitsi tööta.

Ettevõtte SSO on eraldi töö ja seda tasub teha siis, kui kliendiettevõte seda vajab. Kasutaja ID on mõistlik hoida e-postist eraldi, et identiteedi allikat saaks hiljem vahetada.

5. Migratsioonid ja andmemudeli muutmine

Andmebaasi muutmine on igapäevane töö ja selle kord määrab, kui kiiresti saab toodet muuta. Kui muudatused tehakse käsitsi, ei tea keegi, millises olekus tootmiskeskkond on, ja iga juurutus on risk.

Reeglid, mis töötavad ka väikese toote juures:

• Iga skeemimuudatus on fail, mis on versioonihalduses ja mis käivitub samas järjekorras igas keskkonnas.
• Muudatused on tagasiühilduvad: uus veerg lisatakse enne, vana eemaldatakse pärast, kui kood seda enam ei kasuta.
• Andmete ümbertõstmine on eraldi samm, mitte sama samm skeemimuudatusega. Kui see ebaõnnestub, ei ole andmebaas pooleldi muudetud.
• Varundus on olemas ning taastamine kontrollitakse proovitaastega.

See on ka põhjus, miks ma ei armasta „kiireid parandusi“ otse tootmisandmebaasis. Iga selline parandus on muudatus, mida keegi teine ei näe ja mida järgmine migratsioon ei arvesta.

6. AI-funktsiooni koht tootes

AI-funktsioon võib olla lisatud demo jaoks, aga mitte töövoogu. Kolm otsust tuleb teha enne, kui esimene juhis tootesse läheb:

• Kus on piir. Kas AI vastab kliendile või teeb mustandi, mille inimene kinnitab? Kui vastus läheb kliendile ilma inimese kinnituseta, on vea tagajärg teine.
• Kuidas mõõta. Testnäidete kogum ja viis hinnata, kas mudeli või juhise muudatus rikkus tulemuse. Ilma selleta on raske teada, kas muudatus parandas vastuseid.
• Kus lõpeb kulu. Kulupiir kliendiettevõtte või kasutaja kohta ja vahemälu. Ilma kulupiirita võib ühe kasutaja mudelikulu ära süüa teiste kasutajate pealt teenitud kasumi.

Lisandub õiguslik kiht. Kui sinu tootes on AI-funktsioon, on sul Euroopa tehisintellektimääruse (määrus (EL) 2024/1689) järgi roll, mis sõltub muu hulgas sellest, kas arendad või turustad süsteemi oma nime all või kasutad teise pakkuja süsteemi oma tegevuses. Kohustused sõltuvad rollist, süsteemi kasutusotstarbest ja riskist; Euroopa Komisjoni ülevaade tehisintellektimäärusest kirjeldab riskipõhist lähenemist. Eestis valmistub TTJA tehisintellektisüsteemide järelevalve pädeva asutuse rolliks, ja TTJA leht kirjeldab, mida see tooteomanikule tähendab.

Kui AI-funktsioon töötleb isikuandmeid, kehtib sellele määrus (EL) 2016/679. Selle kõrval tasub lugeda ka AKI lehte isikuandmete kustutamise kohta: kustutamistaotluse korral tuleb hinnata ka logides ja mudeli sisendite arhiivis olevat sisu.

Mida nende otsuste juures lepingusse kirjutada

Tehnilised otsused püsivad ainult siis, kui nende tagajärg on lepingus kirjas. B2B SaaS arenduse lehel on omandi kohta neli rida: kood, taristu, dokumentatsioon ja andmed jäävad sinu kätte. Lepingus tasub need lahti kirjutada nii, et need ei ole lubadus, vaid kontrollitav tingimus.

• Kood ja taristu alates esimesest päevast. Kui repositoorium ja pilvekonto on sinu nimel juba esimesel nädalal, ei ole üleandmine hiljem eraldi projekt.
• Andmete eksport on osa tootest. Kui klient lahkub, peab andmete väljavõtmine olema tavaline toiming, mitte kuu aega kestev päring. See on ka parim kaitse selle eest, et rentniku andmemudel jääks liiga kinniseks.
• Kolmandate osapoolte kulud on nähtavad. Makse-, e-posti- ja mudeliteenuse arved on sinu kontol. Eriti AI-funktsiooni puhul, kus kulu kasvab koos kasutusega.
• Muudatuste reegel. Kes otsustab, kui skoop muutub, ja mida see teeb kuupäevale või hinnale. Ilma selle reeglita muutub iga uus soov läbirääkimiseks.

Mida teha esimesel nädalal

Esimese nädala kontrollnimekiri võib olla järgmine:

1. Vali eraldusmudel ja pane see andmebaasi

   Üks tabel, üks veerg, üks reegel, üks test, mis tõestab, et kliendi A kasutaja ei näe kliendi B andmeid.

2. Kirjuta õigused tegude loendina

   Kümme kuni kakskümmend rida. Kontroll serveris, üks funktsioon, mida kutsutakse igast sisenemispunktist.

3. Pane paika tellimuse oleku koht

   Isegi kui arveldust veel ei ole, määra, kus olek elab ja kes seda muudab.

4. Tee kutsevoog ja deaktiveerimine

   Kaks ekraani, mis säästavad hiljem kümneid käsitsi tehtud samme.

5. Lukusta migratsioonide kord

   Üks fail, üks käsk, üks koht, kus see jookseb. Seejärel ära enam kunagi muuda tootmisandmebaasi käsitsi.

Need otsused loovad aluse, millel B2B SaaS arendus pärast esimest versiooni toetub: rentnik, rollid ja tellimuse olek mõjutavad järgmisi funktsioone.

Integratsioonide poolelt on praktiline ülevaade artiklis API integratsioonid, mida Eesti ettevõttes päriselt vaja läheb. Isikuandmete töötlemise kohta on eraldi juhend artiklis AI kasutuselevõtt ettevõttes.