Van idee naar SaaS-MVP: een stappenplan voor oprichters

Bijna elk artikel over het bouwen van een SaaS is stiekem geschreven voor iemand die al geld heeft opgehaald. Het gaat uit van een team, een financiële buffer, een roadmap en de rust van de wetenschap dat u zich een jaar lang kunt veroorloven om ongelijk te hebben. Bent u een oprichter met een echt idee, een vaste baan en spaargeld dat u daadwerkelijk nodig hebt, dan is dat advies stilletjes gevaarlijk. Het zegt u groot en snel te bouwen — en precies zo sterven de meeste eerste producten voordat iemand een cent betaalt.

Ik help mensen al meer dan tien jaar om ideeën om te zetten in werkende software, en de oprichters die mij het meest zijn bijgebleven, zijn niet degenen met de stoutmoedigste plannen. Het zijn degenen die klein begonnen en eerlijk bleven. Een fysiotherapeut die een planningstool bouwde voor haar eigen praktijk en die uiteindelijk aan veertig andere praktijken verkocht. Een logistiek planner die zijn eigen papierwerk automatiseerde en besefte dat de halve branche hetzelfde probleem had. Geen van hen begon met een groots platform. Ze begonnen met één pijnlijke taak en de bereidheid om geld te vragen voor de oplossing.

Dit is dus de gids die ik die mensen op dag één had willen meegeven. Geen geld-ophaal-theater, geen modieuze architectuur, geen gedoe alsof de eerste versie indrukwekkend moet zijn. Gewoon een rustig pad van een vermoeden in uw hoofd naar een eerste betalende klant — en het oordeelsvermogen om te weten wat u onderweg kunt overslaan.

Wat een MVP eigenlijk is (en wat niet)

De term minimum viable product is zo ver opgerekt dat hij nauwelijks nog iets betekent. Sommige oprichters horen "minimum" en leveren iets gênants op dat niemand kan gebruiken. Anderen horen "product" en besteden acht maanden aan een gepolijst platform met prijsniveaus, een beheerderspaneel en een donkere modus, voordat ook maar één mens heeft bevestigd dat hij ervoor zou betalen. Beide zijn fouten, en het is dezelfde fout in andere kleren: bouwen voordat u iets hebt geleerd.

Een bruikbare MVP is het kleinste wat u aan een echte gebruiker kunt voorleggen om te bewijzen dat uw kernidee het betalen waard is. Niet het kleinste wat u kunt bouwen — het kleinste dat u iets waars leert. Is uw idee "een tool waarmee tandartsen automatisch herinneringen voor controles versturen", dan is de MVP de herinneringsmotor en verder niets. Geen patiëntenportaal, geen analysedashboard, geen teamaccounts. Dat zijn antwoorden op vragen die u nog niet hebt verdiend.

De reden dat dit zo belangrijk is, zijn de kosten. Elke functie die u bouwt vóór validatie is een blinde gok. Snijd de MVP terug tot de kern en u plaatst één kleine, terugvorderbare inzet. Bouw de hele visie en u zet uw spaargeld in — op een gok. De discipline van "minimum" gaat niet over zuinig zijn. Het gaat over lang genoeg in leven blijven om gelijk te krijgen.

Valideer het idee voordat u één regel code schrijft

Hier komt de ongemakkelijke waarheid die niemand die u ontwikkeling verkoopt wil uitspreken: de meeste SaaS-ideeën zijn op een belangrijk punt verkeerd, en u kunt daar voor bijna niets achter komen. Het instinct is eerst bouwen en later vragen. Draai het om. De goedkoopste versie van uw product is een gesprek, en de op één na goedkoopste is een landingspagina.

Voordat er iets gebouwd wordt, wilt u bewijs van twee dingen. Ten eerste dat het probleem echt is en pijnlijk genoeg dat mensen er nu al tijd of geld aan besteden — onhandig, met spreadsheets en plakbriefjes en een tool die ze haten. Ten tweede dat ze er oprecht voor zouden betalen om het te laten verdwijnen. "Dat is een leuk idee" is geen bewijs. "Dat zou ik gebruiken" is geen bewijs. "Wat kost het, en kan ik maandag beginnen?" is bewijs.

Een landingspagina met een heldere belofte en een knop "meld u aan voor de wachtlijst" of "plan een demo" is de volgende stap. Lukt het u niet om een handvol onbekenden een e-mailadres te laten achterlaten voor wat u beschrijft, dan is dat geen marketingprobleem om later op te lossen — het is een signaal nu, terwijl het nog goedkoop is om het te horen. Validatie is geen fase die u afraffelt om bij het leuke deel te komen. Voor een oprichter die zijn eigen geld uitgeeft is het het leuke deel: het is waar u de dure fout vermijdt.

Vind de ene functie waar uw product niet zonder kan

Elk SaaS-idee komt, wanneer u het voor het eerst beschrijft, verpakt in een tiental functies. Er is wat het doet, en dan is er de sterrenhemel van leuke extra's die uw brein er al aan heeft gehangen: rapporten, integraties, mobiele apps, rollen en rechten, een openbare API. De allerwaardevolste vaardigheid om van idee naar MVP te komen, is leren om dat allemaal weg te snijden en die ene functie te vinden die, als ze zou verdwijnen, het geheel zinloos zou maken.

Die kernfunctie is uw MVP. Al het andere is een hypothese die u later test, zodra mensen de kern gebruiken en u vertellen wat ze werkelijk missen. Oprichters doen dit stelselmatig andersom — ze bouwen eerst de bijrollen omdat dat veiliger voelt, en raken door hun tijd en geld heen voordat het ene dat ertoe doet ooit wordt opgeleverd.

De één-zin-test

Probeer in één zin te beschrijven wat uw product doet, zonder een "en". "Het laat praktijken automatisch afspraakherinneringen versturen." "Het zet een foto van een bon om in een boekingsregel." "Het houdt bij welke offertes een vakman heeft verstuurd en herinnert hem eraan op te volgen." Hebt u een "en" nodig om de waarde te beschrijven, dan hebt u waarschijnlijk twee producten die binnen één MVP vechten — en moet u de pijnlijkste helft als eerste opleveren.

• Schrijf alles op wat u zich voorstelt dat het product doet — gooi het er allemaal uit, filter niet.
• Vraag u per onderdeel af: als dit niet bestond, zou iemand dan nog steeds betalen? Schrap elke "ja".
• Wat na het schrappen overblijft, is uw kern. Dat is de MVP.
• Zet de sterkste geschrapte onderdelen op een "later"-lijst — niet weg, alleen niet nu.
• Weersta de neiging ze terug toe te voegen. De "later"-lijst is waar goede ideeën wachten om verdiend te worden, niet waar MVP's sterven.

Bouwen, kopen of nabootsen: hoe u de MVP maakt

Zodra u uw ene kernfunctie kent, hebt u een keuze die oprichters zelden bewust maken: hoeveel hiervan moet u eigenlijk vanaf nul bouwen? Het eerlijke antwoord, voor een eerste versie, is meestal "minder dan u denkt". Er zijn drie brede paden, en de slimme zet is vaak een mengeling.

Het no-code- / lijmpad

Voor sommige MVP's kunt u bestaande tools aan elkaar knopen — een formulier, een database, een automatiseringslaag, een e-maildienst — en het idee valideren zonder ook maar één regel maatwerkcode te schrijven. Dit is briljant om te testen of mensen de workflow zullen gebruiken en ervoor zullen betalen. Het is snel en goedkoop. De grenzen tonen zich later: zodra u een echte productervaring, uw eigen datamodel of iets werkelijk unieks nodig hebt, gaat de lijm kraken. Dat is een goed probleem — het betekent dat het tijd is om het goed te bouwen, met betalende gebruikers al in handen.

Het maatwerkpad

Wanneer uw kernfunctie de onderscheidende factor is — de werkelijke reden dat klanten voor u kiezen — dan verdient dat deel echte maatwerksoftware. De fout is om alles eromheen ook op maat te bouwen. U hoeft uw eigen authenticatie, betalingsverwerking of e-mailinfrastructuur niet te schrijven; dat zijn opgeloste problemen die u zou moeten huren. Bouw het deel dat uniek van u is, huur de rest, en u houdt zowel de kosten als de doorlooptijd eerlijk.

De meeste succesvolle MVP's die ik heb gezien, zijn een doelbewuste mengeling: gehuurde bouwblokken voor het saaie-maar-noodzakelijke leidingwerk, en gerichte maatwerkontwikkeling voor het ene dat het product het betalen waard maakt. Weten wat wat is — wat u bouwt versus wat u koopt — is precies het soort beslissing waar het de moeite waard is een tweede mening over te vragen voordat u iets uitgeeft.

Wat u in versie één gerust kunt overslaan

Weten wat u weglaat is even belangrijk als weten wat u bouwt, en het is waar oprichters de meeste toestemming nodig hebben. Dus hier is ze: u hebt toestemming om vrijwel alles over te slaan. De eerste versie bestaat om te leren, niet om indruk te maken, en bijna niets van wat een product "af" doet voelen helpt u eigenlijk om te leren.

• Meerdere prijsniveaus — kies één prijs, of factureer in het begin zelfs handmatig.
• Een selfservice-aanmeldproces — uw eerste tien klanten met de hand inwerken leert u meer dan welke geautomatiseerde funnel ook.
• Een beheerdersdashboard met grafieken — u kunt de database rechtstreeks lezen zolang er tien gebruikers zijn.
• Mobiele apps, als de website het voorlopig prima doet op een telefoon.
• Rollen, rechten en teamaccounts — tot een echte klant er zonder vastloopt.
• Gepolijste instellingen, thema's en elke randgeval — handel eerst het gangbare pad af, de rest wanneer iemand erop stuit.

Een realistisch pad van idee naar eerste klant

Hier is de volgorde waar ik vrijwel elke oprichter doorheen zou loodsen. Hij is bewust traag aan het begin en snel zodra u bouwt, want de dure fouten zitten allemaal in de vroege stappen — die oprichters het meest in de verleiding zijn over te slaan.

1. 1
   Schrijf het probleem in één zin

   Niet de oplossing — het probleem. "Praktijken verliezen geld door no-shows omdat herinneringen handmatig zijn." Kunt u het probleem niet helder formuleren, dan bent u nog niet klaar om het op te lossen.
2. 2
   Voer tien echte gesprekken

   Praat met mensen die het probleem hebben. Luister naar de pijn en naar geld dat al wordt uitgegeven. Pas het idee aan of laat het varen op grond van wat u hoort, niet van wat u hoopte.
3. 3
   Zet een landingspagina en een prijs neer

   Beschrijf de belofte helder, noem een prijs en vraag om een e-mailadres of een demo-afspraak. Kijk of onbekenden meeleunen. Dit is validatie die u kunt vertrouwen.
4. 4
   Definieer de ene kernfunctie

   Snijd het idee terug tot het ene dat, ontbrekend, het zinloos maakt. Schrijf de één-zin-beschrijving zonder "en". Dat is uw bouwomvang.
5. 5
   Beslis bouwen versus kopen per onderdeel

   Bouw alleen de onderscheidende factor op maat. Huur login, betalingen, e-mail en hosting. Krijg deze kaart kloppend voordat iemand code schrijft — ze bepaalt uw hele budget.
6. 6
   Bouw de kleinste werkende versie

   Mik op weken, niet maanden. Als de kernfunctie alleen al langer dan een paar maanden duurt, is de omvang nog te groot — snijd opnieuw.
7. 7
   Werk uw eerste klanten met de hand in

   Loop er persoonlijk met ze doorheen. Kijk waar ze struikelen. De eerste tien gebruikers zijn uw beste productteam — en uw eerste omzet.
8. 8
   Verbeter op basis van gebruik, niet van mening

   Verander wat echt gebruik u zegt te veranderen. Pas nu begint u onderdelen van de "later"-lijst te halen — verdiend door vraag, niet toegevoegd door giswerk.

Wat het echt kost — in geld en in tijd

Oprichters stellen de kostenvraag altijd als eerste, en het eerlijke antwoord is "dat hangt ervan af, en u bepaalt er het meeste van". Veruit de grootste kostendrijver is de omvang — hoeveel u besloot te bouwen voordat u besloot te leren. Een strakke MVP met één kernfunctie, met gehuurd leidingwerk, is een bescheiden, afgebakend project. Hetzelfde idee gebouwd als een volledig platform met alles aangezet is een ander universum aan kosten en een veel grotere kans om te falen vóór de lancering.

De kostenpost die de meeste mensen vergeten is tijd — die van u. Elke maand die u besteedt aan het bouwen van iets waarvan niemand heeft bevestigd dat hij het zal kopen, is een maand van uw leven en uw spaargeld besteed aan een gok. Dat is het echte argument om klein te beginnen: niet dat klein goedkoop is, maar dat klein snel is, en snel betekent dat u leert of u gelijk hebt terwijl de inzet nog terugvorderbaar is. Een oprichter die binnen drie maanden met een smal hulpmiddel een betalende klant bereikt, staat veel sterker dan een die een jaar later nog steeds aan een groots platform sleutelt.

Er is ook een stillere kostenpost: elke functie die u oplevert, is iets dat u nu moet onderhouden, ondersteunen en uitleggen. Een klein product dat één ding betrouwbaar doet, is goedkoper te draaien, makkelijker te verkopen en eenvoudiger te verbeteren dan een uitdijend product dat tien dingen half goed doet. Terughoudendheid is niet alleen hoe u de bouw overleeft — het is hoe u het bedrijf daarna leefbaar houdt.

Veelgestelde vragen