Van idee tot eerste betalende gebruikers: zo lanceerden we een B2B-SaaS

Ze kwam binnen met een spreadsheet, een onderbuikgevoel en een deadline die haar vakcongres haar zonder te vragen had opgelegd. Over vier maanden zou ze op een klein podium staan voor zo'n tweehonderd mensen die precies het soort bedrijf runden dat haar idee moest bedienen. Ze wilde iets echts om te laten zien — geen slides, geen mockup, maar een product waar een vreemde op kon inloggen en voor kon betalen. Dat gesprek is waar deze case study begint, en het nuttigste eraan is hoe gewoon het beginpunt was.

We hebben de herkenbare details hier bewust veranderd. De oprichter is echt, het product is live en de cijfers liggen dicht bij de waarheid, maar afgerond en verzacht zodat niemand kan achterhalen om wie het gaat. Wat telt is niet de specifieke niche — het is de vorm van de reis, want die vorm herhaalt zich bijna elke keer dat een niet-technische oprichter een goed idee in werkende software probeert om te zetten. Sta je ergens aan het begin van die weg, dan is dit ongeveer hoe de komende maanden eruit kunnen zien als het goed gaat.

De korte versie: een branche die ze door en door kende, een pijnlijk handmatig proces dat iedereen erin accepteerde, een spreadsheet waarmee ze het stilletjes beter deed dan haar vakgenoten, en nul technische achtergrond. Elf weken gericht werk later waren de eerste betalende gebruikers binnen. Zo ging het — en, eerlijker gezegd, hier struikelden we.

De situatie: een spreadsheet die echt werk deed

De oprichter runde een klein adviesbureau in een gereguleerd, documentintensief vakgebied. Haar klanten waren andere kleine bedrijven, en stuk voor stuk worstelden ze met dezelfde terugkerende klus — een stapel formulieren verzamelen, ze op volledigheid controleren, de ontbrekende stukken najagen en een nette samenvatting opleveren vóór een deadline. De meeste concurrenten deden dit met e-mail, telefoontjes en een map vol Word-sjablonen. Zij deed het met een spreadsheet die ze in vier jaar had gebouwd en verfijnd, en haar klanten waren er stilletjes dol op.

Die spreadsheet was het hele inzicht. Het was geen businessplan of marktanalyse — het was bewijs. Mensen vertrouwden al op haar tool, vroegen haar of ze hem voor bedrijven wilde draaien die ze niet eens adviseerde, en boden aan te betalen voor alleen al toegang. Als klanten iets willen kopen voordat je het hebt gebouwd, hoef je niet langer te gissen of er vraag is. De vraag was nooit is dit het waard om te doen. De vraag was kan dit software worden die iemand anders kan gebruiken zonder dat zij ernaast zit.

Haar beperkingen waren net zo reëel. Een vast budget uit haar eigen spaargeld, niet uit een fonds. De congresdeadline. En een harde regel die we vroeg afspraken: dit mocht geen project worden dat elke dag haar aandacht opeiste, want ze had nog steeds een adviesbureau te runnen. Wat we ook bouwden, het moest afmaakbaar, betaalbaar en saai in het beheer zijn. Die drie woorden bepaalden elke beslissing die volgde.

De eerste taak was bepalen wat we NIET zouden bouwen

Als oprichters hun droomproduct beschrijven, is de functielijst altijd enorm, want ze fantaseren er al jaren over. De hare vulde twee pagina's: dashboards, teamrechten, een audittrail, automatische herinneringen, een klantportaal, facturatie, analytics, koppelingen met drie tools die haar klanten gebruikten en — natuurlijk — "ergens wat AI erin." Elk item was redelijk. Alles bouwen vóór de lancering was een ramp geworden.

Dus deden we de oefening die we met iedereen doen: voor elke functie stelden we één botte vraag. Als dit op de lanceringsdag zou ontbreken, zou een klant dan weigeren te betalen? Niet "zou het mooier zijn ermee" — zou de verkoop daadwerkelijk sneuvelen. De meeste functies zakken voor die test, en dat is precies de bedoeling. Wat overblijft is je echte product. De rest is een roadmap, een prachtig ding om te hebben, maar niet wat je als eerste bouwt.

Wat overbleef was bijna gênant klein. Een gebruiker kon een account aanmaken, een dossier opzetten, zijn klant uitnodigen om de vereiste documenten te uploaden, en dezelfde nette, gecontroleerde samenvatting terugkrijgen die haar spreadsheet produceerde — maar dan automatisch, en zonder dat zij ertussen zat. Dat was het. Geen dashboards. Geen teamrollen. Geen AI, nog niet. Vier functies, één duidelijke taak, goed gedaan.

Wat we in elf weken echt bouwden

We werken in korte, zichtbare cycli in plaats van drie maanden te verdwijnen en met een verrassing terug te komen. Ongeveer elke week kreeg de oprichter een link naar iets waarop ze kon klikken, ook als het lelijk en half bedraad was. Dat ritme telt zwaarder dan het klinkt: het hield haar beslissingen klein en frequent, in plaats van ze te laten opstapelen tot één angstaanjagende review aan het eind.

Week 1–3: de ruggengraat

Eerst bouwden we de onglamoureuze kern — accounts, een veilige manier om documenten op te slaan, en het datamodel onder de dossierworkflow. Niets hiervan is zichtbaar voor een klant, en juist dit is het deel dat duur is om later te repareren als je het overhaast. Omdat het product met gevoelige papierwinkel van andere bedrijven omging, behandelden we toegangsbeheer en datascheiding als een lanceringsvereiste, niet als een latere upgrade. Dat is een van de weinige plekken waar we weigerden te schrappen.

Week 4–7: het eigenlijke werk

Daarna het deel dat het de moeite van het betalen waard maakte: haar spreadsheet-logica omzetten in de motor die documenten op volledigheid controleert en de samenvatting produceert. Dit was het hart van het product en we gaven het de meeste tijd. We zaten met haar samen en ontleedden waarom elke regel in haar spreadsheet bestond — en verschillende bleken gewoontes te zijn in plaats van vereisten, waardoor we konden vereenvoudigen. Tegen het eind van week zeven kon je een echt dossier van begin tot eind doorlopen.

Week 8–11: het veilig maken om geld voor te vragen

Het laatste stuk was het verschil tussen een demo en een product. Betalen, zodat mensen daadwerkelijk een abonnement konden nemen. Een nette aanmelding die geen handleiding nodig had. De tientallen kleine foutmeldingen die bepalen of een vreemde je software vertrouwt of afhaakt. En testen — saai, repetitief testen — met de oprichter en twee welwillende klanten die het bewust kapot wilden maken voordat vreemden dat deden. Die laatste groep verdiende hun vroegtoegangskorting vele malen terug.

De vraag 'doe er wat AI in', eerlijk beantwoord

Op haar verlanglijst stond AI, zoals op de meeste verlanglijsten nu. We hielden tegengas, en het is de moeite waard uit te leggen waarom, want het is hetzelfde advies dat we bijna iedereen geven. De taak die versie één moest doen — een bekende set documenten controleren tegen een bekende set regels — is een taak die regels beter doen dan AI. Het is voorspelbaar, het is controleerbaar, en als een gereguleerde klant vraagt "waarom markeerde het systeem dit," wil je een helder antwoord, geen schouderophalen.

Dat betekent niet dat AI geen plek had. Er school een echt rommelig, taalgevormd probleem in de workflow: klanten uploadden vaak documenten die bijna goed waren maar verkeerd benoemd, of plakten informatie als vrije tekst in plaats van het formulier in te vullen. Die rommel lezen en sorteren is precies waar moderne AI goed in is. Dus noteerden we het zorgvuldig — en lieten het toen voor versie twee. Het vóór de lancering toevoegen had de deadline vertraagd om een functie te polijsten waar nog niemand voor had willen betalen.

De eerste betalende gebruikers binnenhalen

Dit is het deel waar oprichters zich het meest zorgen over maken en zich het minst op voorbereiden. Een product dat niemand kan vinden is geen bedrijf, het is een hobby. Maar deze oprichter had een voordeel dat meer waard was dan welk marketingbudget ook: ze had al een publiek dat haar vertrouwde, en een paar van hen hadden gevraagd te mogen betalen voordat de software bestond. Het lanceringsplan leunde volledig daarop, en het jouwe zou dat ook moeten als je het hebt.

In plaats van een spetterende publieke lancering deden we het tegenovergestelde — een stille, doelbewuste. Twee weken voor het congres mailde ze het handjevol klanten dat het al had gevraagd, bood hun een founding-member-prijs aan en haalde ze met de hand aan boord, meekijkend via een videogesprek terwijl ze het gebruikten. Elke verwarring werd een fix. Tegen de tijd dat ze op dat podium stond, pitchte ze geen idee; ze beschreef software waar haar vakgenoten al voor betaalden, en dat kon ze eerlijk zeggen.

1. 1
   Begin bij de mensen die er al om vragen

   Haar eerste benadering ging alleen naar klanten die eerder hadden aangeboden te betalen. Warme vraag converteert voordat koude vraag überhaupt antwoordt.
2. 2
   Haal de eersten met de hand aan boord

   Geen zelfbedienings-heldendaden aan het begin. Ze leidde elke vroege gebruiker er live doorheen en maakte van elk verwarringspunt een concrete fix.
3. 3
   Prijs voor founders, niet voor altijd

   Vroege gebruikers kregen een duidelijk in tijd beperkt founding-tarief. Het beloonde hun risico en gaf latere klanten een reden waarom de prijzen omhoog gingen.
4. 4
   Gebruik de deadline als de lancering

   Het congres was geen marketingstunt die er achteraf op werd geplakt — het was de forcerende factor die de afbakening de hele weg eerlijk hield.

Het resultaat — en wat het echt betekent

Tegen het eind van de lanceringsmaand had het product zijn eerste betalende abonnees — een klein aantal, het soort dat je nog op twee handen kunt tellen, stuk voor stuk een echt bedrijf dat een echt maandbedrag betaalt. Dat klinkt bescheiden, en dat is het ook. Het is tegelijk de allermoeilijkste mijlpaal in het hele leven van een softwareproduct. Van nul betalende klanten naar een paar gaan is veel moeilijker dan van een paar naar veel, want het is het moment waarop het idee ophoudt het jouwe te zijn en dat van de markt wordt.

De cijfers hieronder zijn illustratief en afgerond, maar ze blijven trouw aan de vorm van wat er gebeurde. Wat we willen dat je eruit meeneemt zijn niet de getallen — het zijn de verhoudingen. Een strak afgebakende eerste versie, een klein gericht budget, een korte tijdlijn, en een lancering gericht op warme vraag in plaats van op het hele internet.

Waar we het mis hadden

Een case study die alleen overwinningen opsomt is een advertentie, dus hier het eerlijke deel. We maakten twee fouten die het noemen waard zijn, want jij zult in dezelfde verleiding komen.

Ten eerste onderschatten we de onboarding. We hadden het product zorgvuldig afgebakend, maar behandelden de eerste vijf minuten van een nieuwe gebruiker als een bijzaak, iets om aan het eind op te poetsen. Het bleek het make-or-break-moment, en we besteedden een ongeplande week aan het herbouwen van de aanmelding en het lege eerste scherm, zodat een vreemde zonder uitleg kon begrijpen wat te doen. De volgende keer is de eerste ervaring een functie vanaf dag één, niet vanaf week tien.

Ten tweede lieten we één "kleine" regel in de controlemotor uit de hand lopen. De oprichter noemde bijna terloops een randgeval, we waren het eens dat het makkelijk was, en het verslond stilletjes drie dagen omdat de praktijkgegevens rommeliger waren dan haar nette spreadsheet ooit liet zien. De les was niet "vermijd randgevallen" — het was dat haar spreadsheet stilletjes handmatig opschoonwerk deed dat ze vergeten was te doen. Software moet dat onzichtbare werk zichtbaar maken, en dat kost altijd meer dan iemand verwacht.

Als u staat waar zij stond

Wat dit deed werken was geen slimme architectuur of een hippe tool. Het was discipline over afbakening en eerlijkheid over vraag. Ze had bewijs dat mensen het wilden voordat we een regel code schreven, en we waren meedogenloos in het bouwen van de kleinste versie waar iemand toch voor zou betalen. Geen van beide vereist een technische achtergrond. Aan allebei kunt u deze week zelf beginnen.

Hebt u een spreadsheet die mensen u steeds vragen te draaien, of een handmatig proces waarvoor uw klanten u dankbaar zijn, dan bent u misschien dichter bij een product dan u denkt. De gevaarlijke zet is de afgewerkte, functievolledige versie te bedenken en te bevriezen bij hoe groot die eruitziet. Doe het niet. Vind de ene taak die het absoluut moet doen, bouw alleen dat, en leg het voor aan de mensen die er al om vragen. De roadmap kan wachten. De eerste betalende gebruiker niet.

Veelgestelde vragen