Een foundergids voor het solo lanceren van een eerste product: waar een MVP echt voor dient, hoe je de scope terugbrengt tot een enkele zin, de bouwvolgorde die herbouwen voorkomt, de fouten die budgetten opbranden voor er gevalideerd is, en wanneer je geld gaat vragen.
Solo founders, beginnende ondernemers en bouwers van side projects die een productidee valideren zonder technische cofounder en zonder funding.
- Een MVP-scope van een zin die het contact met de werkelijkheid overleeft
- Een bouwvolgorde die validatie voor de afwerking plaatst
- Een duidelijke trigger voor het moment waarop je geld gaat vragen
De meeste eerste producten sterven niet aan slechte code. Ze sterven aan te veel bouwen, te laat valideren en het budget uitgeven voordat iemand had bevestigd dat het idee er een verdiende. Solo lanceren voegde daar vroeger een keiharde beperking aan toe: geen developer. Die beperking is verdwenen, waardoor de overgebleven beperkingen, scope, eerlijkheid en snelheid naar echte gebruikers, het hele spel zijn geworden. Zo speel je het.
Een MVP is geen kleinere versie van je droomproduct. Het is het kleinste dat je voor echte gebruikers kunt zetten en dat antwoord geeft op een vraag: gaan zij dit gebruiken om het probleem op te lossen dat ze volgens jou hebben? Alles wat niet helpt om die vraag te beantwoorden, features, afwerking, schaal, is afleiding totdat het antwoord ja is.
Dit is belangrijk omdat de meest voorkomende mislukking niet technisch is. Het is vier maanden lang features bouwen waar niemand om vroeg, omdat de bouwer het deel oversloeg waarin je daarachter komt. Geen enkele developer, ingehuurd of niet, kan je behoeden voor het bouwen van het verkeerde ding. Alleen contact met gebruikers kan dat, en het hele punt van een MVP is om dat contact zo vroeg en zo goedkoop te maken als eerlijkheid toelaat.
Er gaat een bekend founderverhaal rond over zeventienduizend dollar in de fik steken aan een MVP dat voor die prijs nooit had hoeven bestaan. Het geld kocht geen validatie; het kocht een afgewerkte versie van een onbewezen gok. Houd dat verhaal in gedachten elke keer dat een feature essentieel voelt voordat iemand het product heeft gebruikt.
Vraag een founder wat zijn product doet en je krijgt een alinea. Vraag wat het ene ding is dat een gebruiker doet op het moment dat die voor het eerst waarde krijgt, en de goede founders antwoorden in een zin. Die zin is je MVP.
De visie: een platform voor personal trainers met planning, voedingsschema's, voortgangsfoto's, betalingen en een app voor de klant. De zin: "een trainer kan een klant het trainingsschema van deze week sturen en zien of het is gedaan." Dat is het MVP: twee rollen, een schema, een vinkje. Als trainers zelfs dat niet gebruiken, zou het platform er toch nooit komen; gebruiken ze het wel, dan is er voor elke doorgestreepte feature nu iemand aan wie je ernaar kunt vragen.
Zelfs een MVP van een zin heeft een natuurlijke volgorde, en die respecteren voorkomt de klassieke herbouwspiraal. Elke laag rust op de vorige.
Alleen bouwen betekent dat elke beslissing een gesprek lang duurt. Gebruik die snelheid eerlijk: zet de smalle versie deze week live, leg hem voor aan vijf echte mensen en laat hun gedrag, niet je roadmap, bepalen wat er daarna wordt gebouwd. Teams besteden vergaderingen aan beslissingen die solo founders gewoon kunnen testen.
Eerder dan comfortabel voelt, en later dan het checkout-eerst-kamp beweert. De trigger is gedrag: iemand gebruikt het product twee keer zonder eraan herinnerd te worden, of vraagt of hij het mag blijven gebruiken. Die vraag is de koopintentie; beantwoord haar met een prijs.
De eerste prijs is een test, geen businessmodel. Vraag een bedrag dat vanuit vijf klanten betekenisvol zou voelen en kijk wat er gebeurt: betalende gebruikers die blijven zijn validatie die geen enkele enquête kan faken, en de bezwaren van wie afhaakt vormen de scherpste featureroadmap die je ooit gratis krijgt. Hoe dan ook leer je iets wat een gratis beta verbergt.
En dit is waar het solopad stilletjes het meest is veranderd. Je ene zin beschrijven aan een AI-builder levert je binnen dagen een werkend product op met echte accounts, data en logica, voor ongeveer de prijs van een goed etentje. Dat betekent dat de fout van zeventienduizend dollar nu optioneel is. Het geld dat je niet aan bouwen uitgaf is ademruimte voor het deel dat altijd al het echte werk was: de mensen met het probleem vinden, en luisteren naar wat ze doen met jouw antwoord erop.
Ja. Beschrijf de flow van een zin, wie de gebruikers zijn, wat het product onthoudt en welk resultaat het oplevert, en een AI-builder genereert het werkende product: accounts, database, schermen en logica. Jouw onvervangbare bijdrage was nooit de code; het is het probleem kennen en beoordelen wat gebruikers met de oplossing doen.
Een werkende eerste versie hoort dagen van je tijd en een bescheiden abonnement te kosten, geen factuur van vijf cijfers. De beruchte MVP-fout van zeventienduizend dollar kocht een gepolijste versie van een onbewezen gok; bewaar dat budget om gebruikers te bereiken zodra het idee een hartslag laat zien.
Wanneer een vreemde jouw ene zin zonder jouw hulp kan afmaken: aanmelden, het ene ding doen, het ene resultaat krijgen, met zinnige meldingen wanneer hij iets onverwachts doet. Dat is de hele lat. Meer features maken het niet meer klaar; ze maken het later.
Nee. Voeg een prijs toe in de week dat iemand het product herhaaldelijk gebruikt of vraagt of hij het mag houden, en behandel de eerste prijs als een test met vijf klanten. Een checkout op een onbewezen product meet alleen hoe goed het betaalformulier converteert; eerst gedrag, dan facturering.