Een idee voor software die anderen willen gebruiken? Dat is te bouwen.

SaaS staat voor software as a service: software die als dienst geleverd wordt in plaats van als product dat iemand koopt en installeert. De klant maakt een account aan, logt in via de browser of een app, en betaalt zolang hij het gebruikt. Er is geen schijf, geen installatie op kantoor, geen versie 3.2 die op elke computer bijgewerkt moet worden. Er is één plek waar de software draait en iedereen komt daar langs.

Het verschil met een website is groter dan het lijkt. Een website vertelt iets aan een bezoeker; een SaaS laat iemand werken. Er staan gegevens in die van de klant zijn, er zitten mensen in met verschillende rechten, er gebeurt iets dat morgen nog moet kloppen. Vanaf het moment dat een gebruiker iets kan opslaan dat hij de volgende week terug verwacht, gelden andere regels dan bij een site die alleen leest.

Het verschil met maatwerk voor één opdrachtgever is minstens zo groot. Maatwerk hoeft maar één werkwijze te ondersteunen: die van de opdrachtgever. Een SaaS moet werken voor de tiende klant die het net iets anders doet, en voor de honderdste die iets wil wat de eerste negenennegentig nooit gevraagd hebben. Precies dat maakt de opzet zwaarder en de kans op een goed product groter: elke klant die erbij komt betaalt mee aan hetzelfde geheel.

Er hoeft geen wereldwijd platform uit te komen. Veel van de gezondste producten bedienen een paar honderd bedrijven in één vakgebied, doen precies één ding goed en zijn nooit in het nieuws geweest. Een SaaS is geen ambitieniveau maar een leveringsvorm: software waar mensen op abonnement mee werken.

De sterkste ideeën komen zelden uit een brainstorm. Ze komen uit ergernis: iemand doet al jaren werk waarvan een deel elke week hetzelfde is, houdt dat bij in een spreadsheet die niemand anders begrijpt, en merkt dat collega’s in dezelfde branche precies hetzelfde doen. Dat is het patroon waar een product in zit — een probleem dat vaak terugkomt, bij meerdere bedrijven, op ongeveer dezelfde manier.

Drie voorwaarden zeggen samen bijna alles. Het probleem moet vaak genoeg voorkomen om er iets voor te willen betalen. Er moeten genoeg partijen zijn die het herkennen, want één enthousiaste klant is maatwerk en geen product. En de oplossing moet voor die partijen ongeveer gelijk zijn: als elke klant een fundamenteel andere werkwijze heeft, bouw je tien producten onder één naam.

Een idee dat vooral leunt op “er is nog niets zoals dit” verdient een tweede blik. Soms klopt dat en is de markt net groot genoeg geworden. Vaker is er wel iets, alleen niet zichtbaar vanuit jouw hoek: een oud pakket dat binnen de branche rondgaat, een module in software die klanten toch al hebben, of een dienstverlener die het handmatig doet en er goed van leeft. Weten waar het nu opgelost wordt is waardevoller dan hopen dat het nergens opgelost wordt.

Andersom is concurrentie geen reden om te stoppen. Bestaande producten bewijzen dat er betaald wordt voor de oplossing. De vraag is dan niet of er ruimte is, maar waar de bestaande producten hun gebruikers teleurstellen: te breed, te duur in gebruik, te traag, niet gemaakt voor de manier waarop jouw branche werkt. Een scherp antwoord op die vraag is een beter fundament dan een leeg speelveld.

Onder de noemer SaaS gaan vier heel verschillende producten schuil, met heel verschillende gevolgen. Wie vooraf weet in welke vorm zijn idee valt, herkent de bijbehorende problemen voordat ze zich voordoen.

Het interne gereedschap is de rustigste vorm. Eén organisatie gebruikt het, de gebruikers zijn bekend en zitten desnoods in dezelfde gang. Er hoeft niets verkocht te worden, er is geen aanmeldscherm nodig en fouten worden binnen een dag gemeld door iemand die je kent. Veel producten beginnen hier en groeien pas later naar buiten, als blijkt dat andere bedrijven om hetzelfde vragen.

De verticale SaaS bedient één beroepsgroep: tandtechnici, hoveniers, rijscholen, zorgbemiddelaars. De doelgroep is klein maar scherp, het vakjargon is bekend en één tevreden klant praat met tien anderen op dezelfde beurs. Dit is voor een eerste product vaak de gunstigste vorm, juist omdat er weinig uitgelegd hoeft te worden.

Het brede platform wil van alles voor veel soorten klanten zijn. Dat klinkt groter, maar betekent meer randgevallen, meer uitleg en meer partijen die hetzelfde al doen. De marktplaats is de zwaarste vorm: die moet twee kanten tegelijk binnenhalen, en zonder aanbod komt er geen vraag en zonder vraag geen aanbod. Beide vormen zijn te bouwen, maar het is verstandig om te weten waar je aan begint.

Het meeste van wat een SaaS-idee maakt of breekt is te achterhalen zonder ook maar één regel software. Het kost geen budget, alleen gesprekken en aantekeningen — en het scheelt later het bouwen van functies die niemand mist.

Praten met mensen die het probleem hebben levert meer op dan praten met mensen die je idee leuk vinden. Vraag niet of ze het zouden gebruiken, maar wat ze nu doen: welke stap, hoe vaak, hoe lang, met welk hulpmiddel, en waar het misgaat. Wie vertelt dat hij elke maandag een uur bezig is met iets wat hij haat, geeft betere informatie dan wie zegt dat het “zeker interessant” klinkt.

Even waardevol is uitzoeken hoe het vandaag opgelost wordt. Bijna altijd blijkt er een bestaande manier te zijn: een spreadsheet, een map met formulieren, een medewerker die het handmatig bijhoudt, een pakket dat half past. Dat is de echte concurrent, en het is meteen de maat waarlangs jouw product gelegd zal worden.

Tot slot: schrijf op wat het product níét gaat doen. Die lijst is aan het begin het waardevolste document dat er is. Elk idee groeit tijdens gesprekken, en zonder een grens groeit de eerste versie tot iets wat nooit af komt. Een korte, scherpe beschrijving van wat er wél in zit maakt elk volgend gesprek makkelijker — ook het gesprek met Plaincodelab.

Bij een website is een bezoeker een bezoeker. In een SaaS is bijna niemand alleen: een gebruiker hoort bij een bedrijf, dat bedrijf heeft meerdere medewerkers, en die medewerkers mogen niet allemaal hetzelfde. Die laag — wie hoort waarbij en wie mag wat — bepaalt meer van de opzet dan welke functie dan ook, en is achteraf het duurst om te veranderen.

De eerste vraag is of het product per persoon of per organisatie werkt. Een dagboek-app is persoonlijk; een planningsysteem voor een installatiebedrijf hoort bij het bedrijf, waar de eigenaar alles ziet, een planner de agenda beheert en een monteur alleen zijn eigen bonnen invult. Zodra er meerdere mensen van dezelfde klant in het product zitten, hoort er een niveau boven de gebruiker te bestaan.

Rollen houd je aan het begin bij voorkeur beperkt. Drie rollen die iedereen begrijpt werken beter dan twaalf die niemand kan uitleggen. Wat er wel vroeg in moet zitten is het idee dat rechten per rol gecontroleerd worden op de plek waar de gegevens opgehaald worden, en niet alleen door een knop te verbergen. Een verborgen knop is geen beveiliging; het is een gordijn.

Denk ook aan de randen: iemand die uit dienst gaat, een klant die een medewerker uitnodigt die nog geen account heeft, een eigenaar die het bedrijf overdraagt, een proefaccount dat later een echte klant wordt. Dat zijn geen exotische gevallen maar dagelijkse praktijk, en ze bepalen hoe rustig het beheer straks verloopt.

Een abonnement is geen knop maar een toestand. Een account is in proef, actief, te laat met betalen, opgezegd of verlopen, en het product hoort zich in elk van die toestanden voorspelbaar te gedragen. Dat klinkt eenvoudig tot de eerste betaling mislukt op een zaterdagochtend en niemand weet of de klant er nog in mag.

De meeste producten gebruiken een betaaldienst die de incasso, de kaarten en de herhaling afhandelt; het product zelf onthoudt alleen welke toestand bij welk account hoort. Dat scheelt een enorme hoeveelheid werk en risico, want betaalgegevens hoeven dan nergens in je eigen systeem te staan. Wat wél in je eigen product hoort is de vertaling van die toestand naar wat een gebruiker kan: toegang, grenzen, waarschuwingen.

Bedenk vroeg waar de prijs aan hangt, ook al staat de hoogte nog nergens vast. Per gebruiker, per organisatie, per verwerkt document, per gebruikt volume of een vaste toegang: die keuze bepaalt wat het product moet tellen. Iets wat niet geteld wordt kan later niet gefactureerd worden, en tellers achteraf inbouwen betekent bijna altijd dat de eerste maanden onmeetbaar blijven.

Verder verdienen de saaie gevallen aandacht, want die komen vaker voor dan de mooie. Een klant die tussentijds overstapt naar een ander pakket, een factuur die naar een ander e-mailadres moet dan het account, een boekhouder die om een overzicht vraagt, een opzegging halverwege de periode, btw bij zakelijke klanten in andere landen. Wie die gevallen op papier heeft staan voordat er gebouwd wordt, houdt het later rustig.

In een SaaS staan de gegevens van meerdere klanten in hetzelfde systeem. Dat is de kern van het model en tegelijk de plek waar de grootste fout gemaakt kan worden: één klant die per ongeluk de gegevens van een andere klant ziet. Die scheiding is geen functie die er later bij komt, maar een uitgangspunt dat overal in het product doorwerkt — elke opvraging weet bij welke organisatie de vrager hoort.

Even belangrijk is de vraag van wie de gegevens eigenlijk zijn. Het antwoord is bijna altijd: van de klant, niet van het product. Dat heeft praktische gevolgen. Een klant hoort zijn eigen gegevens te kunnen exporteren in een bruikbaar bestand, zonder erom te hoeven vragen. Een klant die opzegt hoort te weten hoelang zijn gegevens nog bewaard blijven en wanneer ze verdwijnen. Dat vertrouwen wint klanten die eerder ergens vastzaten.

Back-ups zijn geen luxe maar een voorwaarde. Een product waar klanten hun werk in doen, moet terug kunnen naar gisteren als er iets misgaat — door een storing, door een fout in een nieuwe versie of doordat iemand per ongeluk iets wist. Bewaren op dezelfde plek als het origineel telt niet als back-up. Dit is nodig voor elk product dat serieus gebruikt wordt; wie het beheert is een aparte keuze, die per situatie anders uitpakt.

Tot slot: bedenk vooraf wat er níét in het product hoeft. Elk gegeven dat je niet opslaat, kan niet lekken, hoeft niet beveiligd te worden en levert geen vragen op bij een klant die om verantwoording vraagt. Vooral bij bijzondere gegevens — gezondheid, financiën, kinderen — is de goedkoopste beveiliging nog altijd: het niet vastleggen.

Zodra een SaaS gegevens van andere bedrijven verwerkt, verandert de juridische rol. De klant is dan verwerkingsverantwoordelijke en het product is verwerker: het doet iets met gegevens namens die klant. Daar hoort een verwerkersovereenkomst bij, en zakelijke klanten vragen er vroeg of laat om — soms al bij het eerste gesprek, zeker in de zorg, het onderwijs en de financiële hoek.

Een paar dingen komen in elke beoordeling terug. Waar staan de gegevens fysiek, en blijven ze binnen de Europese Unie? Welke andere partijen krijgen ze te zien, bijvoorbeeld een betaaldienst, een e-maildienst of een foutmelder? Hoelang worden ze bewaard? Wie binnen jouw organisatie kan erbij? En wat gebeurt er als er iets misgaat: hoe merk je het, wie wordt gewaarschuwd en binnen welke termijn.

Rechten van betrokkenen zijn geen papieren kwestie maar functionaliteit. Iemand mag zijn gegevens inzien, laten corrigeren en laten verwijderen. Een product waarin dat alleen handmatig kan, kost elke maand tijd; een product waarin het geregeld is, verkoopt zichzelf aan de klant die de vraag stelt. Datzelfde geldt voor een verwerkingsregister en een korte, leesbare uitleg over wat er precies bewaard wordt.

Verder is er wetgeving die per branche verschilt: bewaartermijnen in de zorg, eisen aan facturatie, regels rond kinderen, sectorafspraken over toegang. Dat hoort in kaart voordat de opzet vastligt, want het raakt de gegevens die je bewaart en de manier waarop je ze scheidt. Plaincodelab bouwt met die eisen als uitgangspunt; wie ze pas achteraf ophaalt, bouwt twee keer.

Bij een SaaS is beveiliging geen extraatje maar onderdeel van het product dat verkocht wordt. Klanten geven hun werk uit handen, en de eerste vraag van elke iets grotere klant gaat over hoe dat werk beschermd is. Het goede nieuws: het grootste deel bestaat uit degelijke basis, niet uit exotische maatregelen.

Die basis is bekend. Wachtwoorden worden versleuteld bewaard en nooit terugleesbaar opgeslagen. Sessies verlopen en zijn in te trekken. Tweestapsverificatie is beschikbaar voor wie het wil, en verplicht te maken voor beheerders. Elke opvraging controleert opnieuw of deze gebruiker deze gegevens mag zien. Uploads worden gecontroleerd op type en grootte. Formulieren en inlogpogingen kennen een limiet, zodat proberen niet loont.

Daarnaast hoort er zicht te zijn op wat er gebeurt. Een logboek van belangrijke handelingen — wie logde in, wie wijzigde rechten, wie verwijderde iets — helpt bij vragen van klanten en bij het uitzoeken van incidenten. Meldingen bij ongebruikelijke patronen zijn nuttiger dan een lange lijst met regels die niemand leest.

Ten slotte hoort er een plan te zijn voor het moment dat er iets misgaat. Niet omdat het waarschijnlijk is, maar omdat het antwoord dan al klaar moet liggen: hoe wordt een lek gemeld, wie informeert de klanten, hoe wordt een oude toestand teruggezet en wat wordt er daarna aangepast. Klanten vergeven een storing; ze vergeven zelden een stilte.

Klanten gebruiken jouw product naast alles wat ze al hebben. Een boekhoudpakket, een agenda, een kassa, een voorraadsysteem, een e-maildienst, een pakket voor loonadministratie. De vraag is niet óf er gekoppeld gaat worden, maar waarmee eerst — en die vraag is beter te beantwoorden door de doelgroep dan door een aanname.

Koppelingen zijn vaak het verschil tussen “leuk product” en “onmisbaar product”. Zodra gegevens niet meer overgetikt hoeven te worden, wordt overstappen naar een ander product duur voor de klant en wordt jouw plek in hun dag vanzelfsprekend. Het is dan ook zelden verstandig om er tien tegelijk te beloven: één koppeling die vlekkeloos werkt levert meer op dan vijf die half werken.

Andersom is een eigen programmeerinterface het gereedschap waarmee anderen bij jou aansluiten. Voor de meeste producten is dat geen eerste zorg, maar het is wel een reden om de gegevens netjes te ordenen: een product dat vanaf het begin een duidelijke structuur heeft, kan die interface later openzetten zonder alles om te bouwen. Voor klanten met een eigen IT-afdeling is de vraag ernaar een teken van serieuze interesse.

Let ten slotte op afhankelijkheid. Elke koppeling is een partij die kan veranderen, duurder kan worden of kan stoppen. Dat is geen reden om ze te vermijden, wel om te weten wat er gebeurt als de koppeling wegvalt: blijft het product bruikbaar, of staat alles stil? Dat antwoord hoort bekend te zijn voordat de klant het vraagt.

Een product met drie klanten en een product met driehonderd zijn twee verschillende dingen, ook al is het dezelfde software. Wat verandert is niet zozeer de techniek als wel de omgang: een klant die je persoonlijk kent, mailt over een probleem; een klant die je niet kent, zegt op zonder iets te zeggen. Groei betekent dat je dingen moet kunnen zien die je eerst gewoon hoorde.

Aan de technische kant zit de eerste rem meestal niet in het aantal bezoekers maar in zware handelingen: een rapport dat alle gegevens doorrekent, een export van een jaar, een bestandsverwerking die per klant groeit. Dat soort werk hoort op de achtergrond te gebeuren, zodat één zware klant niet het scherm van alle anderen vertraagt. Het is verstandig dit vroeg te scheiden, ook al is het bij drie klanten nog niet te merken.

Aan de organisatorische kant komen er vragen bij die niets met bouwen te maken hebben. Wie beantwoordt de e-mails, hoe worden nieuwe klanten wegwijs gemaakt, wat gebeurt er als twee grote klanten tegengestelde wensen hebben, en welke wensen worden wel en niet gebouwd. Een product zonder duidelijke lijn wordt vanzelf het gemiddelde van alle wensen — en daarmee van niemand meer echt goed.

Ten slotte verandert de manier waarop verbeteringen doorgevoerd worden. Bij drie klanten kun je iets aanpassen en het even melden. Bij driehonderd zit er altijd iemand midden in zijn werk. Aankondigen, testen op een aparte omgeving en kunnen terugvallen op de vorige toestand horen dan bij het normale ritme.

Een SaaS is geen opdracht die af is, maar een dienst die loopt. Dat is het eerlijkste dat erover te zeggen valt. Klanten werken erin, hebben vragen, komen fouten tegen en verwachten dat er iemand is. Dat vraagt aandacht van de eigenaar, ook wanneer het bouwen bij een ander ligt.

Concreet betekent dat een paar dingen. Er is een plek waar klanten terechtkunnen met vragen, en iemand die daar antwoord geeft. Er is duidelijkheid over wat er gebeurt bij een storing. Er is iemand die beslist welke wensen er wel en niet in gaan. En er is een omgeving waar het product draait, met de rekeningen en verantwoordelijkheden die daarbij horen — dat hoort bij het product, ongeacht wie het beheer uiteindelijk uitvoert.

Verder hoort er ruimte te zijn voor onderhoud dat niemand ziet. Onderdelen krijgen nieuwe versies, koppelingen veranderen, beveiligingsproblemen in gebruikte bibliotheken worden gepubliceerd en moeten opgelost worden. Dat werk levert geen nieuwe functie op, maar het is de reden dat een product na jaren nog steeds werkt.

Dat alles is te organiseren, en Plaincodelab denkt daarin mee: welke taken bij jou horen, welke bij een technische partij en welke bij de dienstverleners eromheen. Waar dat precies neerkomt verschilt per situatie, en wordt vastgelegd voordat er gebouwd wordt — niet als bijzin achteraf.

Bij een website gaat meten over bezoek. Bij een SaaS gaat meten over gebruik, en dat is een ander gesprek. De vraag is niet hoeveel mensen langskwamen, maar of ze binnen zijn gekomen tot het punt waarop het product zijn werk doet — en of ze daarna terugkomen.

Het belangrijkste moment heet activatie: de eerste keer dat een nieuwe gebruiker het resultaat ziet waarvoor hij kwam. Bij een facturatieproduct is dat de eerste verstuurde factuur, bij een planningsysteem de eerste ingeplande week. Wie ziet hoeveel mensen dat punt níét halen, weet precies waar het product hen kwijtraakt — vaak in een scherm dat de bouwer volstrekt logisch vond.

Daarnaast zijn er een paar dingen die elke eigenaar wil kunnen zien zonder erom te vragen: hoeveel accounts er actief zijn, welke onderdelen echt gebruikt worden, waar mensen vastlopen, hoeveel klanten opzeggen en wat ze als reden opgeven. Dat laatste is geen statistiek maar goud: opzeggingen vertellen eerlijker waar het product tekortschiet dan enquêtes onder tevreden klanten.

Meten hoeft niet te betekenen dat je gebruikers volgt. Voor de meeste vragen is het genoeg om te tellen wat er in het product gebeurt, zonder profielen op te bouwen of gegevens naar derden te sturen. Dat past bij de privacyverwachting van zakelijke klanten en scheelt bovendien uitleg in elk beveiligingsgesprek.

De meeste klanten die afhaken, haken af voordat ze iets gedaan hebben. Ze melden zich aan, komen in een leeg scherm terecht, weten niet waar te beginnen en sluiten het tabblad. Alles wat daarna in het product zit — de doordachte rapportage, de slimme koppeling — hebben ze nooit gezien. Het eerste kwartier is daarmee het belangrijkste deel van een SaaS.

Een leeg scherm is de grootste boosdoener. Een nieuw account hoort niet leeg te zijn maar uitnodigend: een voorbeeld dat laat zien hoe het eruitziet als het gevuld is, een eerste stap die in één handeling af te ronden is, of de mogelijkheid om bestaande gegevens in te lezen zodat iemand meteen zijn eigen situatie herkent. Wie zijn eigen naam in het product ziet staan, blijft langer kijken.

Uitnodigen hoort daar direct achteraan. In de meeste producten wordt pas waarde zichtbaar als er collega’s bij zitten: een planning zonder team is een agenda, een dossier zonder tweede lezer is een tekstbestand. Een uitnodiging die in twee klikken verstuurd wordt en die de ontvanger op de juiste plek laat binnenkomen, doet meer voor het gebruik dan welke functie dan ook.

Tot slot: bedenk wat er gebeurt als iemand na een week terugkomt. Weet het product nog waar hij gebleven was? Staat er een korte hint over de volgende stap? Wordt er een enkel bericht gestuurd dat helpt in plaats van irriteert? Dat soort details bepaalt of een proefaccount een klant wordt, en ze zijn goedkoper te bedenken vooraf dan achteraf.

Een SaaS bouwen en een SaaS verkopen zijn twee verschillende dingen, en het tweede begint eerder dan de meeste eigenaren verwachten. Software die niemand kent, wordt door niemand geprobeerd. Dat betekent niet dat er een marketingafdeling nodig is, maar wel dat er nagedacht wordt over hoe iemand met dit probleem bij dit product terechtkomt.

Bij een verticale SaaS lopen de eerste klanten meestal via mensen: een branchevereniging, een vakbeurs, een appgroep waar collega’s in zitten, een leverancier die dezelfde doelgroep bedient. Dat is trager dan een advertentie maar duurzamer, omdat de mensen die het aanraden weten waar ze het over hebben. Voor veel producten zijn de eerste tien klanten letterlijk bekenden van bekenden.

Daarnaast zoeken mensen naar hun probleem, niet naar jouw productnaam. Iemand typt wat hij wil oplossen: een manier om iets bij te houden, een systeem voor een bepaalde taak, een alternatief voor een pakket dat te duur of te log is. Een productsite die die vragen letterlijk beantwoordt — in gewone woorden, met uitleg over wat het wel en niet doet — wordt gevonden en genoemd, ook door assistenten die namens gebruikers samenvatten.

Wat daarbij helpt is duidelijkheid over wat het product is. Voor wie het bedoeld is, welk probleem het oplost, wat er wel en niet in zit en hoe je kunt kijken zonder meteen ergens aan vast te zitten. Producten die dat vaag houden, worden vergeleken op prijs; producten die het scherp maken, worden vergeleken op geschiktheid.

De meeste SaaS-producten stranden niet op techniek. Ze stranden op keuzes die aan het begin logisch leken en later niet meer terug te draaien waren, of op een eerste versie die zo groot werd dat er nooit een klant in kwam.

De bekendste is te veel willen. Elk gesprek levert een goed idee op, elk idee lijkt klein, en samen worden ze een product dat maanden later nog steeds niet toonbaar is. De tegenhanger is even schadelijk: een versie die zo kaal is dat niemand er zijn werk in kan doen en er dus ook niets uit te leren valt.

Daarna volgt bouwen voor één klant. Een eerste klant die meebetaalt is goud waard, maar wie al zijn wensen inbouwt, levert maatwerk met een abonnementje. Het onderscheid tussen “dit heeft iedereen nodig” en “dit wil deze ene klant” is de belangrijkste keuze die een eigenaar herhaaldelijk maakt.

De rest van de lijst hieronder komt in vrijwel elk eerste product terug. Ze zijn allemaal te vermijden door ze vooraf te herkennen — en dat is precies waarom ze hier staan.

Een idee is klaar wanneer het in één zin uit te leggen is aan iemand uit de doelgroep, en die persoon meteen begrijpt waarom het bestaat. Niet omdat de zin mooi is, maar omdat het bewijst dat het probleem scherp is. Alles wat daarna komt — schermen, koppelingen, abonnementen — is invulling van een keuze die al gemaakt is.

Verder helpt het als er antwoord is op vier vragen. Wie is de gebruiker, en wie beslist over aanschaf? Welke stap in hun week wordt hiermee makkelijker? Wat doen ze vandaag in plaats daarvan? En wat zit er uitdrukkelijk niet in de eerste versie? Wie die vier op papier heeft, heeft meer voorwerk gedaan dan de meeste beginnende producten.

Wat niet nodig is om te beginnen: een volledig uitgewerkt ontwerp, een naam die iedereen mooi vindt, een businessplan van dertig pagina’s of zekerheid over alles wat er later bij komt. Die dingen groeien onderweg mee. Wat wél nodig is, is dat de eerste versie klein genoeg is om echt bij mensen te komen, en groot genoeg om er hun werk in te kunnen doen.

Plaincodelab bouwt SaaS-producten met de technieken die bij het product passen — niet met één vaste keuze die overal overheen gelegd wordt. Wat er nodig is hangt af van wat het product moet doen, met wie het praat en wie het gaat gebruiken. Die afweging wordt uitgelegd voordat er gebouwd wordt, in gewone taal, zodat je zelf kunt volgen waarom iets zo opgezet wordt.