De meeste softtech-start-ups lopen niet vast door een gebrek aan ambitie, maar doordat ze te snel en te groot bouwen op aannames die nooit getoetst zijn. In dit artikel neem ik je mee door de aanpak die ik met Kings Code al jaren samen met onze opdrachtgevers doorloop. Je leest waarom ik altijd eerst met de opdrachtgever aan de slag ga met de validatie voordat er gebouwd wordt, waarom klein beginnen je juist sneller laat groeien, hoe je de ontwikkelpartner kiest die bij jouw fase past en waarom een goed product na livegang eigenlijk nog maar net begonnen is. Maar vooral hou je een idee eigenlijk succesvol maakt!
Softtech gaat over het bouwen van digitale oplossingen waarbij software zelf het middel is om iets nieuws mogelijk te maken. Denk aan een SaaS-platform of een app. Het is een van de snelst groeiende categorieën binnen het Nederlandse start-uplandschap, en toch zie ik steeds weer dat nieuwe initiatieven opeens weer verdwenen zijn. En dat komt meestal weer door precies dezelfde valkuilen; ze bouwen te vroeg te veel, praten te laat met hun klanten of kiezen een ontwikkelpartner zonder na te denken over wat er na de eerste oplevering gebeurt. In dit artikel neem ik je mee door het proces dat wij bij Kings Code samen met onze opdrachtgevers hebben doorlopen, van het eerste idee tot een product waar klanten daadwerkelijk voor betalen.
Softtech vraagt om een andere aanpak dan een gewoon it-project
Softtech-producten zijn nooit helemaal af en zelden in één keer goed. Anders dan bij een fysiek product, of een traditioneel it-project met een vaste opleverdatum, blijft software voortdurend veranderen. Gebruikers, technologie en de markt evolueren maar bovenal leer jij jouw markt steeds beter kennen en kun je daardoor de problemen ook steeds beter oplossen. Jouw product moet hierrin meebewegen om echt waarde te kunnen leveren voor jouw klant. Dat vraagt een andere mentaliteit dan eerst alles willen specificeren en dan pas bouwen. De rode draad in dit stappenplan is dan ook geen rechte lijn van A naar B, maar een cyclus die je steeds opnieuw doorloopt, valideren, klein bouwen, leren en bijsturen.
Technische validatie is de eerste stap, nog voordat er één regel code geschreven wordt
De helft van alle software-ideeën blijkt in de oorspronkelijke vorm gewoon veel te duur. Ik zie heel vaak gebeuren dat mensen met een goed iee hun product meteen op grote schaal voor zich zien, met duizenden gebruikers, een uitgebreide architectuur en dashboards vol functionaliteit. Maar het begin altijd bij de eerste vraag: Hoeveel klanten heb je nu eigenlijk? Ik heb dit in de praktijk meegemaakt met een opdrachtgever die ons vroeg om een platform te bouwen voor duizenden gebruikers, terwijl hij bij de start enkele tientallen klanten had. Om direct een systeem te bouwen voor duizenden gebruikers zou een kostbare investering worden, gebaseerd op een enkele aanname. Namelijk dat er duizenden gebruikers gaan komen. Het kan namelijk ook best zijn dat het idee de andere kant op gaat en met enkele honderden key users net zo waardevol is. Wij bouwden in plaats daarvan dus een systeem voor een paar honderd gebruikers, met de ruimte om later op te schalen. Twee jaar later draaide het nog altijd probleemloos, inmiddels voor ruim tweehonderd klanten.
De les die ik hieruit meeneem is dat succes vaak afhangt van hoe snel je bereid bent je technische ambities aan te passen aan de realiteit van vandaag, in plaats van vast te houden aan de droom van over vijf jaar.
Praat met klanten voordat je gaat bouwen
Wil je weten of je idee kans van slagen heeft, praat dan met minimaal twintig potentiële klanten over hun werk en de bijbehorende probleem, niet over jouw oplossing. Validatie voelt misschien als vertraging want je bent overtuigd van je idee maar is de manier om een product te ontwikkelen waar mensen echt voor betalen. Het lastige bij het interviewen van potentiële klanten is dat mensen je niet willen kwetsen. Ze zeggen al snel wat je graag wilt horen. Daarom vraag je nooit of iemand een idee goed vindt maar liever hoe iemand een probleem nu oplost en wat daarbij het grootste struikelblok is. Deze manier van vragen stellen wordt de Mom Test genoemd. In dit blog leg ik uitgebreider uit hoe je met de Mom Test je software-idee kunt valideren.
Bij een start-up die ik heb mogen begeleiden in de publieke sector heb ik dit van dichtbij kunnen meemaken. De opdrachtgever dacht een groot probleem in deze sector te kunnen oplossen omdat er veel tijd besteed werd hieraan. Uitendelijk bleek dat men het helemaal niet erg vond om tijd te besteden hieraan. Dan los je weliswaar iets op maar omdat niemand het als een probleem ervaart, heeft je product opeens veel minder kans van slagen. Een conclusie die we gelukkig vroeg hebben weten te trekken. Uit de interviews kwamen wel echte pijnpunten naar voren en met die route is het product uiteindelijk succesvol geworden!.
Begin klein, dat is waarom de lean startup-aanpak werkt
Bouw eerst de kleinst mogelijke versie van je product die mensen al kunnen gebruiken, en breid pas verder uit zodra je weet waar de behoefte ligt. Lean betekent niet goedkoop of half werk. Het betekent slim omgaan met je tijd en je geld. Grote softwarebedrijven zijn precies zo begonnen. Salesforce startte als een simpele online contactenlijst, Slack was een interne chattool en Zoom bood in de eerste jaren alleen videobellen aan. Pas toen die kern perfect werkte en klanten ervoor betaalden, kwamen de extra functies.
Een Nederlandse start-up in de detacheringssector paste dit principe letterlijk toe. In plaats van een compleet systeem te bouwen, begonnen ze met één functie, het bijhouden van contacten in een eenvoudig CRM. Na vier maanden hadden ze een werkende eerste versie. Na acht maanden gebruikten collega's het dagelijks. Na zestien maanden kon het oude systeem de deur uit. Het resultaat was een systeem dat 70 procent goedkoper uitpakte dan de oorspronkelijke plannen, met functionaliteit die vanaf dag één daadwerkelijk werd gebruikt. Meer over deze lean startup-aanpak lees je hier.
Kies je ontwikkelpartner op basis van de fase waarin je zit
De juiste ontwikkelpartner hangt af van waar je start-up staat, niet van hoe een partij zichzelf noemt. In de fase van idee naar prototype heb je iemand nodig die kritische vragen stelt over je businessmodel en je doelgroep. Een partner die meteen in technische details duikt zonder je zakelijke doelen te begrijpen, is een slecht teken. Zodra je van prototype naar product beweegt, wordt continuïteit belangrijker. Heeft de partner een solide basis staan waar je jaren op kunt bouwen? Is er voldoende expertise en flexibiliteit in huis?
Grofweg zijn er drie manieren om samen te werken. Je kunt keizen voor een vaste prijs, oftewel op projectbasis. De kosten zijn voorspelbaar maar de kwaliteit helaas niet. Afwegingen worden in deze opzet vaak commercieel gemaakt. Een andere optie is om een freelancer in te huren. Dit is vaak voordelig maar ook erg risicovol. Niemand houdt toezicht op kwaliteit en de afhandelijkheid is groot. Bij uitval heb je een groot bedrijfrisico. Een derde optie is om te kiezen voor een team van professionals met verschillende expertises die gezamenlijk je product doorontwikkelen. De uitkomst is hierbij minder voorspelbaar maar de kwaliteit hoog en de ontwikkeling krijgt een vast ritme. Ik werk dit verschil verder uit in dedicated team, projectbasis of freelancer.
Minstens zo belangrijk als het model is het contract. Wie wordt eigenaar van de broncode, en kun je zonder lange opzegtermijn stoppen als de samenwerking niet meer werkt? Deze en andere afwegingen heb ik gebundeld in 7 vragen voordat je een ontwikkelpartner kiest.
Je hoeft geen developer te zijn om de juiste technische keuzes te maken
Wat wel helpt, is weten welke vragen je moet stellen over platform, architectuur en beveiliging. Alles begint bij je doelgroep. Werken je gebruikers achter een bureau, dan is een online applicatie meestal de logische keuze. Zijn ze veel onderweg, dan telt een mobiele oplossing zwaarder mee. Pas als dat helder is, kies je tussen een online applicatie, een cross-platform app of een volledig native app. Ik zet de afwegingen op een rij in welk platform bij jouw gebruikers past.
Ook de onderliggende architectuur speelt mee. Je kunt eenvoudig beginnen met een monoliet of direct modulair opzetten, en de keuze voor een bewezen, open source framework zoals Laravel bepaalt hoe je product zich later laat opschalen. Security en privacy zijn geen features die je achteraf toevoegt. Bouw je product vanaf dag één met security & privacy by design, inclusief de basis op orde voor de AVG en de European Accessibility Act.
Werk in korte sprints, dan houd je grip op je product
Agile ontwikkelen betekent dat je in vaste periodes van meestal twee weken werkt aan concrete, vooraf afgesproken onderdelen, met aan het eind van elke sprint een moment om te controleren en bij te sturen. Dat geeft je als founder overzicht, voorspelbaarheid en controle over je budget. Je ziet elke twee weken werkende software, in plaats van maanden te wachten op één grote oplevering. Lees meer hierover in agile werken in sprints.
Je software is na livegang nog maar net begonnen
Zodra je applicatie wordt gelanceerd begint het avontuur pas echt. Je ontvangt feedback van de eerste gebruikers, je leert je doelgroep beter kennen en je krijgt nieuwe inzichten. Na de eerste lancering begint je product pas echt aan te sluiten bij de doelgroep en ga je doorontwikkelen om product-market-fit te optimaliseren. Je applicatie is daarom nooit af, er is altijd iets te optimaliseren of als extra feature toe te voegen. Ik werk dit verder uit in waarom software nooit "af" is.
De valkuilen die ik steeds weer zie bij startende founders
De grootste valkuilen zijn steeds dezelfde. Founders willen in één keer een compleet platform bouwen voordat ze ook maar één betalende klant hebben. Ze praten te weinig met echte gebruikers. Ze vergeten budget te reserveren voor onderhoud. En ze stoppen met doorontwikkelen zodra de eerste versie live staat. Elk van deze fouten kost founders geld en tijd die ze niet meer terugkrijgen. Ik bespreek ze uitgebreid, met concrete voorbeelden, in veelgemaakte fouten van startende founders.
Mijn founder-kompas, tien vragen voordat je begint
Loop de volgende tien vragen na en tel hoe vaak je volmondig ja kunt zeggen. Kun je de meeste met 'Ja' beantwoorden, dan is het tijd om serieus met een ontwikkelpartner in gesprek te gaan.
- Heb ik met minimaal 20 potentiële klanten gesproken over hun probleem?
- Kan ik in één zin uitleggen welk probleem mijn product oplost?
- Wat is de kleinst mogelijke versie die al waarde levert?
- Heb ik budget gereserveerd voor de eerste 12 maanden na livegang?
- Weet ik of mijn gebruikers vooral desktop of mobiel werken?
- Heb ik nagedacht over wie eigenaar wordt van de broncode?
- Ken ik het verschil tussen projectmatig werken en een dedicated team?
- Weet ik welke vragen ik aan een potentiële ontwikkelpartner moet stellen?
- Heb ik een idee van de technische haalbaarheid van mijn concept?
- Ben ik bereid mijn oorspronkelijke idee aan te passen op basis van feedback?
De uitgebreide versie van dit lijstje, met toelichting per vraag, vind je in 10 vragen voordat je begint.
Zet nu de volgende stap
Dit stappenplan is een onderdeel van mijn handboek "Van idee tot succesvolle software", en het is de aanpak die we met founders in de praktijk brengen. Wil je sparren over de technische haalbaarheid van jouw idee, of wil je weten welke aanpak bij jouw fase past? Plan een vrijblijvende sparsessie of * download het volledige handboek* voor alle praktijkvoorbeelden, checklists en mijn founder-kompas per hoofdstuk.