Een SaaS-idee begint vaak met functies. Gebruikers kunnen inloggen, gegevens beheren, rapporten ontvangen, samenwerken en betalen per maand. Dat klinkt als een product, maar het zijn nog vooral bouwstenen.

Voordat je SaaS laat maken, moet je weten of er een herhaalbaar probleem, een herkenbare koper en een werkbare manier van leveren bestaat. Software vergroot wat al duidelijk is. Ze maakt een zwakke aanname niet automatisch waar.

De belangrijkste voorbereiding is daarom geen lange featurelijst, maar bewijs voor zeven aannames.

1. Welk probleem en welke koper?

Beschrijf het probleem zonder jouw oplossing te noemen. Bijvoorbeeld niet: “bedrijven hebben een AI-dashboard nodig”, maar: “teamleiders verzamelen iedere week informatie uit meerdere systemen en kunnen afwijkingen te laat zien.”

Maak daarna onderscheid tussen gebruiker, beïnvloeder, beslisser en betaler. Dat kunnen verschillende personen zijn. Een medewerker kan dagelijks voordeel ervaren, terwijl een manager budget vrijmaakt en IT of compliance toestemming moet geven.

Beantwoord:

Wie ervaart het probleem direct?
Wie bepaalt of er iets aan wordt gedaan?
Wie draagt de kosten van de huidige situatie?
Wie kan de aankoop blokkeren?
Is het probleem belangrijk genoeg om nu te veranderen?

Een brede doelgroep als “het MKB” is niet specifiek genoeg voor een eerste product. Kies een situatie waarin probleem, taal en werkproces voldoende op elkaar lijken om gericht te kunnen testen.

2. Hoe wordt het probleem nu opgelost?

Een alternatief is niet alleen concurrerende software. Het kan ook een spreadsheet, e-mail, WhatsApp, handmatig werk, een externe dienstverlener of simpelweg niets doen zijn.

Observeer de huidige werkwijze stap voor stap:

Wat start het proces?
Wie doet wat?
Welke informatie wordt gebruikt?
Waar wordt gekopieerd, gecontroleerd of gewacht?
Welke fouten of uitzonderingen komen terug?
Hoe wordt het resultaat beoordeeld?

De bestaande workaround laat zien welk gedrag werkelijk belangrijk is. Een functie die in gesprekken aantrekkelijk klinkt, maar waarvoor niemand nu tijd, geld of moeite inzet, is nog geen bewezen behoefte.

Zoek niet alleen frustratie. Zoek ook beperkingen. Misschien is het probleem vervelend maar zeldzaam. Misschien werkt de handmatige oplossing goed genoeg. Misschien kan de organisatie niet de gegevens leveren die automatisering nodig heeft.

3. Welke betalingsbereidheid moet worden bewezen?

Interesse is geen betalingsbereidheid. “Dat zou handig zijn” bewijst niet dat iemand budget, tijd en intern draagvlak inzet.

Test daarom een concrete ruil:

Wil de koper tijd vrijmaken voor een pilot?
Wil die toegang geven tot realistische data?
Wil die een intentieverklaring, reservering of betaald traject aangaan?
Welk budget wordt nu al besteed aan het probleem of de workaround?
Welke uitkomst moet de investering rechtvaardigen?

Prijs is niet alleen een rekensom. Ze bepaalt ook welk serviceniveau, welke verkoopinspanning en welke support mogelijk zijn. Een product dat veel handmatige begeleiding nodig heeft, kan niet worden beoordeeld alsof levering volledig zelfstandig verloopt.

Je hoeft vóór de bouw geen perfecte prijs te kennen. Je moet wel aantonen dat een realistisch aanbod voor beide kanten zinvol kan zijn.

4. Rollen, data en terugkerende workflows

SaaS wordt pas een product wanneer verschillende klanten grotendeels hetzelfde kernproces kunnen gebruiken. Maatwerk per klant kan in het begin nuttig zijn om te leren, maar maak zichtbaar wat structureel is en wat uitzondering blijft.

Beschrijf:

welke rollen bestaan;
welke handelingen iedere rol mag uitvoeren;
welke data wordt ingevoerd, aangepast en geëxporteerd;
welke stappen in een vaste volgorde verlopen;
waar goedkeuring nodig is;
welke uitzonderingen niet automatisch kunnen worden afgehandeld;
welke configuratie per klant verschilt.

Let vooral op het systeem van waarheid. Waar hoort een gegeven officieel te leven? Wat gebeurt er wanneer dezelfde informatie in meerdere systemen verschilt? Wie mag een correctie uitvoeren?

Een workflowdiagram met echte uitzonderingen is waardevoller dan een schermlijst. Het maakt duidelijk of het product een herhaalbaar proces ondersteunt of alleen een mooie laag boven onopgeloste organisatorische verschillen vormt.

5. De kleinste verkoopbare eerste versie

Een MVP wordt soms uitgelegd als de goedkoopste versie die technisch werkt. Voor SaaS is dat te beperkt. De eerste versie moet klein zijn, maar wel een volledige waarde-uitwisseling mogelijk maken.

Een verkoopbare eerste versie heeft:

één duidelijke doelgroep;
één belangrijk probleem;
één kernworkflow van begin tot resultaat;
voldoende rollen en rechten om veilig te testen;
een werkbare manier voor onboarding en support;
een meetbaar succescriterium;
een handmatige fallback wanneer automatisering nog niet betrouwbaar is.

Schrap functies die alleen toekomstmogelijkheden demonstreren. Bouw bijvoorbeeld geen uitgebreid beheerdashboard wanneer de eerste klanten met een eenvoudige interne procedure kunnen worden ondersteund. Bouw geen complex abonnementsmodel voordat duidelijk is hoe klanten werkelijk kopen.

De juiste vraag is niet: “Wat hoort bij een professioneel SaaS-platform?” De juiste vraag is: “Wat moet volledig werken zodat een echte klant het probleem kan oplossen en daar bewust voor kiest?”

6. Support en operationeel eigenaarschap

SaaS eindigt niet bij oplevering. Iemand moet verantwoordelijk zijn voor:

vragen van gebruikers;
foutmeldingen en incidenten;
onboarding;
wijzigingen in processen of externe systemen;
gegevenscorrecties;
account- en toegangsproblemen;
monitoring en herstel;
communicatie bij verstoring.

Maak vóór de bouw duidelijk welke support in het product kan worden opgelost en welke support menselijk blijft. Een onduidelijke workflow wordt vaak een supportprobleem. Een ontbrekende foutmelding wordt een e-mail. Een slechte import wordt een handmatige datacorrectie.

Reken deze werkzaamheden mee in het verdienmodel. Een lage abonnementsprijs kan onhoudbaar zijn wanneer iedere klant veel inrichting of persoonlijke begeleiding nodig heeft.

7. Beveiliging, privacy en go/no-go

Beveiliging is geen eindcontrole. De aard van de data, rollen en acties bepaalt vanaf het begin hoe het product moet worden ontworpen.

Breng minimaal in kaart:

welke gegevens worden verwerkt;
waarom die gegevens nodig zijn;
wie toegang krijgt;
welke acties onomkeerbaar of gevoelig zijn;
welke externe partijen data ontvangen;
hoe toegang wordt ingetrokken;
hoe gebeurtenissen worden gelogd;
wat er gebeurt bij een fout of incident.

Formuleer daarna een go/no-go-besluit.

Ga door wanneer

het probleem terugkerend en belangrijk is;
een herkenbare koper actief wil testen;
de huidige workaround concreet is;
een realistische vorm van betaling of commitment bestaat;
de kernworkflow bij meerdere klanten voldoende overeenkomt;
noodzakelijke data en toegang beschikbaar zijn;
support en risico binnen het beoogde model passen.

Stop of herformuleer wanneer

het probleem vooral theoretisch is;
iedere klant een ander kernproces nodig heeft;
niemand verantwoordelijkheid wil nemen voor invoer of uitkomst;
de waarde alleen ontstaat bij een onrealistische hoeveelheid data of adoptie;
risico’s groter zijn dan de eerste versie verantwoord kan beheersen;
de oplossing pas werkt nadat meerdere onbewezen afhankelijkheden tegelijk slagen.

Bouw pas wanneer je weet wat je probeert te bewijzen

SaaS laten maken is geen manier om onzekerheid te vermijden. Het is een investering om een bewezen workflow schaalbaar en beheersbaar te maken. Toets daarom eerst de zeven aannames en bouw vervolgens de kleinste versie die een echte klant van probleem naar resultaat brengt.

Lees hoe maatwerksoftware een specifiek proces kan ondersteunen, wat bij een webapplicatie komt kijken en hoe Omnitechs projecten benadert in onze werkwijze.