Een MVP; ik heb Springcast voor €6000 laten bouwen

Vlak nadat ik met mijn podcast, Growth Minds, was gestart, wilde ik mijn podcast op Spotify en Apple hebben. Ik zocht uit wat daarvoor nodig was en kwam er al snel achter dat ik podcast hosting nodig had om dat voor elkaar te krijgen. Maar ik ontdekte ook dat er geen Nederlandse aanbieders waren.

Mijn interesse was gewekt, want ik heb in het verleden een hostingbedrijf gehad (en verkocht) en zat al heel diep in de contentwereld. Bovendien wilde ik naast mijn Business coaching zelf weer ondernemen en was ik op zoek naar een mooie kans.

Et voila… alles kwam samen. Mijn achtergrond, ervaring, interesse en professionele situatie.

En dan? Hoe begin je als business coach (of zzp’er) een nieuw bedrijf ernaast, zonder alles over boord te gooien was je tot nu toe hebt opgebouwd?

Milestones.

Werken met milestones is het antwoord. Klein beginnen, valideren of het kan groeien en langzaam opschalen tot alle seinen op groen staan. De komende weken deel ik die milestones en mijn ervaring daarmee. Nu gaan we bij de eerste stilstaan… Een MVP.

Eerst even kort… wat is een MVP?

MVP staat voor Minimal Viable Product. Het is feitelijk het meest uitgeklede product waar je mee wegkomt in de markt. Meestal bevat het alleen de hoogst noodzakelijke functies.

Met de eerste versie van Springcast kon je;

• een podcast aanmaken;

• afleveringen aanmaken;

• een RSS-feed aanmaken;

• Basis statistieken bekijken.

Meer kon je er niet mee. En in principe hadden veel mensen niet meer dan dat nodig. En zoals je ziet, zat er nog niet eens betaalmogelijkheid in. Eerst maar eens kijken wat er zou gebeuren bij de lancering.

Hoe minimalistisch een MVP kan zijn, hangt ook af van de volwassenheid van de gebruiker. Als deze al goede tools gewend is, moet je MVP ook uitgebreider.. of beter zijn. In dat geval zou je 1 ding heel goed kunnen doen. Beter dan alle concurrenten.

Springcast MVP-fase

De MVP-fase voor Springcast moest 2 dingen valideren, namelijk;

1. Kunnen we de technologie bouwen?

2. Kunnen we het met een redelijke investering doen?

In die volgorde ben ik begonnen met valideren. En voor elk deel had ik green/orange/red lights. Als ze beiden op groen zouden staan, zou ik doorgaan naar de volgende fase.

Want iedere fase kost geld … of in ieder geval tijd. En tijd is geld, dus bij een red light, zou ik onmiddellijk stoppen (in deze fase).

Kunnen we het technisch bouwen?

Hierbij was vooral de grootste uitdaging het genereren van statistieken. Er was nergens te vinden hoe de Amerikaanse concurrenten dat deden, dus we moesten hier zelf iets voor kunnen bedenken. Bovendien had ik een budget van €5.000 dat ik in deze fase wilde investeren.

Ik heb een MVP-bouwer ingehuurd die uiteindelijk voor €6.000 een MVP kon bouwen. We gebruikten daarvoor Wordpress als fundament. Het was niet mooi. En het was ook niet echt schaalbaar, maar genoeg voor de eerste test.

Het lukte ons binnen 4 weken om de MVP te bouwen. Het was absoluut nog niet iets om trots op te zijn, maar het voldeed voor de eerste test.

Wat ik van het Springcast-MVP heb geleerd

Persoonlijk vond ik het heel erg moeilijk om niet direct een paar ‘nice to have’ functies toe te voegen. In de MVP-fase moet je echt je ego loskoppelen van wat je op dat moment aan het doen bent.

Ik ben zelf een app liefhebber en verplaats me dan ook direct in de gebruiker. Later is dat een kracht, maar in de MVP-fase is het vooral een risico. Maar uiteindelijk heb ik me redelijk kunnen inhouden, mede door de feedback MVP-bouwer ;) en bouwden we de core van Springcast 0.1.

Het tweede wat ik ervan heb geleerd, is dat je een hele duidelijke briefing moet voorbereiden voor de MVP-bouwer. Wat komt erin, hoe ziet het er ongeveer uit, hoe werkt de flow? Zie hieronder hoe ik in Apple Notes schermen tekende als begeleiding bij de briefing.

Het beste kun je met post-its of met tools, zoals Miro, Figma of Milanote een flow uitwerken. Het kost heel veel tijd vooraf, maar dat betaalt zichzelf dubbel en dwars terug. Ik heb daar wat bochtjes afgesneden en gelukkig kwam het uiteindelijk allemaal goed.

Wat ik volgende keer anders zou doen

Ik zou een paar dingen anders doen, namelijk;

1. Geen Wordpress als fundament gebruiken

2. Nog betere briefing voor de MVP definiëren

Op zich heb ik geen spijt van hoe ik deze MVP-fase heb aangepakt, maar door deze twee zaken anders te doen, zou ik het mezelf in de toekomst makkelijker maken.

Wordpress leek sneller om te starten, want een groot deel van wat er moest komen, zat al in Wordpress. Maar tijdens het ontwikkelen van het MVP, zorgde de enorme code-base van Wordpress regelmatig voor onverwachte problemen en vertragingen. Voor een volgende MVP zou ik altijd custom code laten bouwen.

Ik zou een nog betere briefing voorbereiden. Ik zou uitdenken hoe een scherm is opgebouwd, wat er in de schermen komt te staan en beschrijven wat iedere functie, knop of functie moet doen. En als er al concurrenten bestaan, wellicht zelfs hun fundament als basis gebruiken. Dit versnelt het ontwikkelproces en verkleint de kans op ‘meerwerk’ en dus kosten.

Aanbevelingen & Resources

• Ken je geen developers? Probeer dan eens een developer in te huren via Upwork of Fivvr. Heeft me meermaals verrast!

• Wees snoeihard naar jezelf over wat er in de MVP nodig is. Beide kanten op. Het moet wel goed genoeg zijn, maar niet te uitgebreid … succes daarmee ;)

• Voor Pro tips op dit vlak lees je ook de nieuwsbrief