Een MVP is de kleinste versie van je SaaS-platform die een echt probleem oplost voor echte klanten. De afkorting staat voor minimum viable product. Wie een eigen softwareplatform wil lanceren, heeft vaak een lange lijst met ideeën. Toch is het verstandig om niet met alles tegelijk te beginnen. In dit artikel lees je waarom een MVP de beste start is en hoe je bepaalt wat erin hoort.
Wat een MVP is, en wat niet
Eric Ries maakte de term bekend met zijn lean-startupaanpak. Volgens The Lean Startup draait het om een lus van bouwen, meten en leren. Je bouwt iets kleins, meet hoe klanten reageren en beslist daarna of je doorgaat of bijstuurt.
Een MVP is geen half afgewerkt product of een prototype vol fouten. Het is een volwaardige toepassing, alleen met een beperkte reikwijdte. Denk bijvoorbeeld aan een planningstool die eerst alleen ploegen inplant en uren registreert. Facturatie en een app volgen dan later. De functies die erin zitten, werken goed, zijn veilig en zien er verzorgd uit. Wat ontbreekt, zijn de extra’s die je pas nodig hebt als je weet hoe klanten het platform echt gebruiken.
Waarom klein beginnen loont
Elke functie die je bouwt, kost tijd en geld, en moet je daarna ook onderhouden. Bouw je meteen alles, dan investeer je in aannames. Misschien gebruiken klanten die uitgebreide rapportage nooit, terwijl ze een eenvoudige export wel elke dag nodig hebben. Dat weet je pas als ze ermee werken.
Een MVP brengt je sneller bij die eerste gebruikers. Zo hoor je vroeg wat werkt en wat niet. Bovendien kan je soms al inkomsten halen uit de eerste versie, wat de verdere ontwikkeling mee kan dragen. Moet je het idee bijsturen, dan verlies je minder tijd en geld aan onderdelen die je weggooit.
Wat hoort in de eerste versie
Begin bij één duidelijke doelgroep en één kernprobleem. Beschrijf daarna de kortste weg die een gebruiker aflegt om dat probleem op te lossen. Alles wat op die weg ligt, hoort in de MVP. Wat daarbuiten valt, zet je op een lijst voor later.
Daarnaast heeft elke SaaS een aantal fundamenten die je niet kan overslaan:
- Accounts en aanmelden, met een veilig wachtwoordbeheer
- Een strikte scheiding tussen klanten, zodat niemand andermans gegevens ziet
- Rollen en rechten, als meerdere mensen van één klant het platform gebruiken
- Een manier om klanten te laten betalen, of minstens een plan daarvoor
- Back-ups, logboeken en basisbeveiliging
Die fundamenten lijken minder spannend dan de kernfunctie, maar ze achteraf toevoegen is veel moeilijker. Daarom bouwen we ze van bij de start mee.
Leren voor je bouwt
Soms kan je al leren voor er één regel code bestaat. Een eenvoudige landingspagina die het idee uitlegt, toont bijvoorbeeld of mensen zich willen inschrijven. Gesprekken met een handvol potentiële klanten leren je vaak meer dan weken bouwen. Ook een klikbaar ontwerp helpt, omdat gebruikers de schermen al kunnen doorlopen voor de ontwikkeling start.
Zo’n voorbereiding maakt de MVP scherper. Je weet dan welk probleem het zwaarst weegt, welke woorden je doelgroep gebruikt en welke functie echt het verschil maakt. Daarna bouw je met meer zekerheid, en blijft de eerste versie klein zonder dat ze leeg aanvoelt.
Een MVP bouwen zonder later opnieuw te beginnen
Klein beginnen betekent niet dat je slordig mag bouwen. Een bekende valkuil is een snel in elkaar gestoken eerste versie die je na een jaar volledig moet herschrijven. Daarom kiezen we een technische basis die kan meegroeien. Bij in2sites bouwen we een SaaS in Laravel, met Livewire of met React op een Laravel-API. Zo voeg je later functies toe zonder de fundamenten te vervangen.
Ook privacy hoort bij een degelijke basis. Een SaaS bewaart gegevens van je klanten, en vaak ook van hun klanten. De regels van de GDPR gelden dus vanaf de eerste gebruiker. Denk bijvoorbeeld aan een verwerkersovereenkomst, duidelijke bewaartermijnen en de mogelijkheid om gegevens te verwijderen.
Na de lancering van je MVP: meten en bijsturen
De lancering van je MVP is het begin van het leerproces. Spreek met je eerste gebruikers, kijk welke functies ze gebruiken en waar ze vastlopen. Hou een lijst bij van vragen en verzoeken, en zoek naar patronen in plaats van elke wens meteen te bouwen.
Plan daarna korte ontwikkelrondes. Elke ronde voegt iets toe dat je gebruikers aantoonbaar nodig hebben, of verbetert iets dat niet goed werkt. Zo groeit je platform op basis van gebruik, niet op basis van vermoedens. Goed UX-design helpt daarbij, omdat je schermen test voor je ze bouwt.
Heb je een idee voor een SaaS-platform? Lees meer over een SaaS laten ontwikkelen, of vertel ons via de contactpagina welk probleem je wil oplossen.
