Bewijs de werkende week van één trainer voordat je vindbaarheid, uitbetalingen en ondersteuning voor meerdere trainers toevoegt.
Case · Boekingsproduct · Opdrachtgever Ruud
Padel Next Level
Een gericht lesboekingsproduct voor één echte trainer en zijn leerlingen: één gedeelde boekingswaarheid in plaats van afstemming via WhatsApp, zonder marktplaatscomplexiteit voordat de kernweek werkt.
Voor wie
Ruud is de trainer, beheerder en tester namens de opdrachtgever. Zijn leerlingen moeten een agenda kunnen openen, zien wanneer hij beschikbaar is en daar boeken — zonder op chat te wachten. Ruud heeft één plek nodig voor beschikbaarheid en boekingen zodat hij niet steeds “wanneer kun je?” hoeft te appen of zijn planning opnieuw hoeft te sturen.
Mijn rol
Product- en technisch eigenaarschap: V1-kader, rolflows, productregels, discipline in opleveren/reviewen en acceptatiestappen die Ruud kan lezen en testen. De beperking was bewust: laat de echte coachweek van één trainer werken voordat je een sportmarktplaats ontwerpt.
Probleem
Every lesson starts as a coordination problem. Leerlings need a suitable moment without a WhatsApp exchange. Ruud needs to publish availability, plan one-off and weekly lessons, and know who is joining — without reconstructing the week from chat threads. Before the product, that meant constant back-and-forth: “when can you?”, “are you free Thursday?”, sending availability again and again.
Ontwerpvraag: wat is het kleinste betrouwbare systeem voor de echte coachweek van één trainer, vóór enige marktplaatscomplexiteit?
Inzicht
Marketplace features before one trainer’s week works create discovery, support, and operational debt. The product is not “more ways to find padel”; it is one booking truth with two role-specific interfaces. Leerlings need certainty about a lesson. Ruud needs an operational view of tomorrow. Both depend on the same protected lesson data.
Opties
- A · Marktplaats-V1 met meerdere trainers — bredere ambitie, maar rollen, vindbaarheid, uitbetalingen en ondersteuning vóór de primaire workflow is bewezen.
- B · WhatsApp plus spreadsheet — vertrouwd, maar elke boeking vraagt handmatige afstemming en de waarheid van de agenda blijft verspreid.
- C · Gericht boekingsproduct alleen voor Ruud — gekozen: één trainer, één boekingsmodel en aparte schermen voor leerling en trainer.
Koerswijziging
We schrapten betalingen, wachtlijst, gamification, Google-login en informeel slepen-en-neerzetten uit V1. Die functies kunnen later nuttig zijn, maar maken de eerste betrouwbare boekingslus lastiger om te bouwen en testen. Het product scheidt nu een rustige boekingsflow voor leerlingen van een werkruimte voor de trainer — twee interfaces, één datamodel.
Kernflow met twee kanten
Leerling
Kies dag → bekijk aanbod → kies vorm/tijd → boek → vind het onder Mijn lessen.
Mobiel-eerst boeken houdt traineradministratie buiten de beslissing van de leerling.
Trainer
Stel beschikbaarheid in → maak losse les of wekelijkse reeks → beheer capaciteit en spelers → houd de agenda als operationele waarheid.
Ruud krijgt een beheerscherm, geen consumentenapp met achteraf toegevoegde beheerdersknoppen.
Eén boeking, beide kanten
De leerling heeft zekerheid nodig. De trainer heeft een operationeel overzicht van morgen nodig.
Bewijs van leerling
“Geboekt” is een status, geen toastmelding
De aangeleverde screenshot uit producttesten houdt de komende les zichtbaar met datum, starttijd, duur, vorm en huidige groepsgrootte. Een leerling kan later terugkomen en de afspraak nog steeds begrijpen.
Getoond als een eerdere productstatus, niet als de huidige live-UI.
Productregels achter de interface
Eén boekingswaarheid: capaciteit en geboekte status komen uit hetzelfde beschermde datamodel.
Reeksen zonder geschiedenis te verliezen: wekelijkse lessen kunnen stoppen terwijl eerdere exemplaren begrijpelijk blijven.
Niveau is nuttige context: leerlingen hebben een niveau; de trainer kan dit corrigeren wanneer de coachpraktijk afwijkt.
De trainerbeelden gebruiken de echte applicatie-UI met een geïsoleerde lokale backend en duidelijk fictieve deelnemers. Er zijn geen productieaccounts of leerlingdata gebruikt.
Leerlingen boeken vanuit een rustige mobiele flow. Ruud beheert agenda, reeksen, beschikbaarheid, spelers en niveaus in een trainerwerkruimte.
Geen betalingen, wachtlijst, gamification, Google-login of informeel slepen-en-neerzetten in V1. Betrouwbaarheid wint van een lang functiemenu.
Resultaat & eerlijkheid over bewijs
Het product is live op padelnextlevel.nl met publieke registratie, aparte rollen voor leerling/trainer, boekingsschermen, profielbeheer, terugkerende lessen en productie-uitrol.
Wat veranderde voor Ruud: hij hoeft leerlingen niet meer voortdurend te appen over wanneer hij wel of niet les kan geven, of steeds zijn beschikbaarheid rond te sturen. Leerlingen openen de agenda, zien vrije momenten en boeken daar — één gedeelde boekingswaarheid in plaats van chatgesprekken.
Gebruik (live Supabase, aug 2026): gebruikt door 151 leerlingen + Ruud als trainer · 70 leerlingen met minstens één boeking · 361 boekingen · 148 lessen.
De beelden van leerlinghome/profiel zijn vastgelegd in het live product met een tijdelijke portfolio-testleerling; het test-e-mailadres en telefoonnummer zijn weggelaten. De aangeleverde geboekte status is gelabeld als een eerdere productstatus. Trainerbeelden komen uit de echte UI met een geïsoleerde lokale backend met fictieve deelnemers. Er is geen echte les geboekt en er worden geen productiegegevens van leerlingen getoond.
Hierna
Observeer eerst hoe Ruud en leerlingen de boekingslus herhaaldelijk gebruiken met minder handmatige afstemming. Vereenvoudig daarna randgevallen in trainerreeksen en maak het no-showbeleid voor leerlingen begrijpelijk. Betalingen komen pas nadat de kernboekingswaarheid vertrouwd wordt.