Too Good To Go koppelt winkels en horeca met eten dat over is aan gebruikers die dat aanbod reserveren, betalen en binnen een vast tijdvak ophalen. Onder die ene handeling zit een voorraadsysteem met een tijdvak, een reserverings- en betaalflow en een ophaalcheck, een opzet die zich net zo goed leent voor bloemen, behandelplekken, sportlessen of parkeerplekken met restcapaciteit. OneDayBuild is niet verbonden aan Too Good To Go; deze pagina ontleedt het model, niet het merk.
Onder de app zit een klein aantal functies die het model dragen. De rest is uitbreiding, geen fundament.
Too Good To Go, opgericht in 2015 in Kopenhagen (meer over de geschiedenis), verkoopt zogeheten Magic Bags: verrassingspakketten met eten dat een winkel of horecazaak die dag niet kwijtraakt, af te halen binnen een vast tijdvak. Wie het model wil nabouwen voor een andere markt, bloemen, behandelplekken, sportlessen, doet er goed aan om eerst te scheiden wat de kern draagt en wat later kan.
Een groot deel van het systeem leg je met bestaande bouwstenen. Het eigen werk zit in de match tussen voorraad, tijdvak en reservering.
Een PSP zoals Mollie, Stripe of Adyen regelt iDEAL, creditcard en restituties. Dat bouw je niet zelf, dat koppel je aan.
Authenticatie via een bestaande login-library en push- of e-mailmeldingen via een notificatiedienst zijn kant-en-klare integraties.
Een kaart-library toont waar het aanbod ligt en hoe ver een gebruiker moet reizen. Dat is een integratie, geen apart bouwwerk.
Wat overblijft is minder zichtbaar, maar dat is wel het echte bouwwerk. De matching-logica tussen voorraad, tijdvak en reservering moet concurrency-veilig zijn: als twee gebruikers tegelijk op dezelfde laatste Magic Bag klikken, mag er maar één winnen. Daarnaast is er een dashboard nodig aan de kant van de aanbieder, los van de app aan de kant van de gebruiker, en een simpele maar betrouwbare manier om een ophaling te bevestigen. Voor een MVP is dat precies het stuk waar je tijd in stopt, en de rest laat je aan bestaande diensten over.
Het lastige deel zit niet in de techniek van de flow, maar in wat eromheen moet kloppen.
Een marktplaats zoals Too Good To Go heeft twee kanten nodig die tegelijk groeien: zonder genoeg aanbieders is er voor gebruikers geen reden om de app te openen, en zonder genoeg gebruikers is er voor aanbieders geen reden om aan te sluiten. Die kritische massa is het lastigste deel van het model, en het is ook de reden dat de meeste nabouwers klein beginnen: één keten, één stad, of zelfs één aanbieder, voordat de andere kant erbij komt.
Daarnaast moet je vooraf een eerlijk beleid bepalen voor gemiste ophalingen. Too Good To Go compenseert een gemiste ophaling niet, om aanbieders en andere gebruikers die het aanbod ook wilden niet te benadelen; annuleren kan tot een paar uur voor het tijdvak. Verkoop je fysieke producten, dan komt daar mogelijk regelgeving bij, denk aan voedselveiligheid als het om eten gaat, of vergunningen als het om iets anders gereguleerds gaat. En elke betaalflow vraagt om een restitutiebeleid dat standhoudt zodra er echt geld omgaat.
De kosten die hierbij horen zijn factoren, geen vaste bedragen: het transactievolume, het aantal aanbieders dat je onboardt en begeleidt, en de mate waarin je voorraad en tijdvak live moet synchroniseren tussen aanbieder en gebruiker. Hoe die factoren voor jouw idee uitpakken, hangt af van de markt die je kiest.
Niet het hele platform, maar de kernflow: aanbod plaatsen, reserveren, betalen en ophalen, met echt aanbod van een of twee aanbieders.
Een aanbieder, bijvoorbeeld een bakker of een sportschool met losse plekken, zet zijn restcapaciteit voor die dag in het prototype: een aantal en een ophaal-tijdvak.
Een tester reserveert via het prototype en rondt een testbetaling af. De voorraad telt meteen een stuk terug, zichtbaar voor iedereen die daarna kijkt.
De tester komt langs binnen het tijdvak en toont de code. De aanbieder bevestigt de overdracht, en de reservering sluit.
Samen bekijk je wat wel en niet werkte, en wat er nodig is om naar een tweede aanbieder of een grotere groep gebruikers te gaan. Wie de scope daarna wil scherpstellen, kan dat met de mvp-scope-slicer doen.
Het overschot-model past niet op elk idee. Een paar situaties waarin je beter iets anders bouwt.
Too Good To Go zelf richt zich op voedseloverschot bij winkels en horeca. Het onderliggende model, aanbod met een tijdvak plus reservering en ophaling, is breder toepasbaar op andere vormen van restcapaciteit, zoals bloemen, behandelplekken of sportlessen.
Nee. Begin met één aanbieder of één stad om de reserveer-en-ophaalflow te valideren, voordat je de andere kant van de markt erbij haalt. Kritische massa is een groeivraagstuk voor later, geen voorwaarde voor een eerste versie.
Een PSP zoals Mollie of Stripe handelt de betaling af. In een prototype werk je vaak met een testomgeving van die PSP, zodat de flow werkt zonder dat er al echte transacties nodig zijn.
Bepaal vooraf een eerlijk beleid, bijvoorbeeld geen restitutie bij een gemiste ophaling en een moment waarop een aanbieder de reservering mag annuleren. Too Good To Go hanteert zo'n beleid ook, om aanbieders en andere gebruikers niet te benadelen.
Eén of twee aanbieders zijn genoeg om te zien of de flow werkt en of gebruikers hem oppakken. Meer aanbieders werven is een volgende stap, geen onderdeel van de eerste validatie.
Je hebt een werkend prototype en concreet gebruikersgedrag om op door te bouwen of juist bij te sturen. Wie de vervolgstap wil vastleggen, kan dat doen met de projectbrief-generator.
In één werkdag bouwen we een klikbare reserveer-en-ophaalflow voor jouw idee, met echt aanbod van een of twee aanbieders, zodat je ziet of mensen het gebruiken.
Een korte intake volgt na je inschrijving. Daarna stemmen we scope en datum af.
We nemen contact op om de intake in te plannen.
We gebruiken cookies om je ervaring te verbeteren en het gebruik van de site te meten.