BezorgFlex: een flexwerk-platform bouwen voor de horeca — van idee tot productie

Het probleem De horecasector kampt al jaren met een krappe arbeidsmarkt. Op piekmomenten — een zonnig weekend, een festival, een drukke vrijdagavond — schiet het vaste bezorgteam van veel restaurants simpelweg tekort. De gangbare oplossing is aansluiten bij een groot bezorgplatform zoals Thuisbezorgd, Uber Eats of Deliveroo, maar dat betekent commissies tot wel 15–30% per bestelling én weinig grip op wíe er daadwerkelijk aan de deur staat.

Tegelijkertijd is er een grote groep scholieren en jongeren die graag flexibel wil bijverdienen naast school, maar voor wie de toegang tot betrouwbaar, goed geregeld werk vaak versnipperd en informeel is — via-via, zonder heldere afspraken over loon of voorwaarden. BezorgFlex is mijn antwoord op dat probleem: een tweezijdig marketplace-platform dat functioneert als een soort digitaal uitzendbureau tussen horecagelegenheden en jonge flexwerkers. Het concept Het platform onderscheidt twee doelgroepen aan de aanbodkant: Bezorgers (15 t/m 20 jaar) — leveren bezorgdiensten op fiets of e-bike, op de momenten dat restaurants zelf te weinig capaciteit hebben.

Lichte hulpkrachten (13 en 14 jaar) — voeren niet-industriële hulparbeid van lichte aard uit, zoals handmatig afwassen en schoonmaakwerk in de keuken, binnen de wettelijke grenzen die voor deze leeftijdsgroep gelden. Restaurants plaatsen shifts: datum, taken, aantal benodigde personen en het geboden uurloon. Werkzoekenden geven hun beschikbaarheid op en worden gematcht — automatisch op basis van beschikbaarheid, waarderingsscore en afstand, met de mogelijkheid tot handmatige selectie. Na afloop van elke shift ontvangt de werkende een waarderingsscore, die meeweegt bij toekomstige matching. Het platform verdient aan servicekosten die bovenop het uurloon bij de restaurants in rekening worden gebracht — nadrukkelijk niet bij de werkenden zelf.

Wat dit project extra interessant maakt, is dat de techniek eigenlijk niet het lastigste onderdeel is. Omdat een deel van de doelgroep minderjarig is, moest ik vanaf de eerste ontwerpkeuze rekening houden met kinderarbeidwetgeving, de Arbeidstijdenwet, AVG-regels rond gegevens van minderjarigen, en de juridische kaders van uitzendwerk (Waadi, WTTA-vergunningsplicht). Dat betekent dat de applicatie hard geprogrammeerde blokkades bevat: een 13-jarige gebruiker krijgt simpelweg geen bezorgshift te zien, en werktijden worden automatisch getoetst aan de wettelijke grenzen per leeftijdscategorie. Vertrouwen — richting zowel de jongere als de ouder — is daarmee net zo goed een productvereiste als een marketingboodschap.

De techniek

Voor de bouw koos ik voor een moderne, type-veilige stack: Next.js 16 (App Router) met TypeScript als fundament — voor zowel de publieke pagina's als het ingelogde dashboard voor werkzoekenden en restaurants. Tailwind CSS voor de styling. Supabase (PostgreSQL) als backend voor database en authenticatie — ideaal voor een project waar ik snel wilde itereren zonder zelf een volledige backend te bouwen. Turbopack als build-tool, standaard meegeleverd met de nieuwste Next.js-versie. Een service worker en web manifest, zodat het platform als Progressive Web App installeerbaar is — belangrijk voor een doelgroep die vrijwel uitsluitend op mobiel zit. Deployen op eigen infrastructuur In plaats van te kiezen voor een platform-as-a-service zoals Vercel, wilde ik volledige controle houden over de hosting en heb ik gekozen voor een eigen VPS met Plesk als beheerpaneel. Dat bleek een leerzame exercitie op zich.

Het uitgangspunt was simpel: code pushen naar een Git-repository, en Plesk laten zorgen voor de deployment naar productie. In de praktijk kwam daar behoorlijk wat bij kijken: Node.js koppelen aan het domein. Plesk's Node.js-ondersteuning moest eerst per domein geactiveerd worden — niet vanzelfsprekend te vinden, want de knop zat niet waar ik 'm verwachtte. Uiteindelijk bleek dit via de domeinspecifieke Node.js-manager te moeten, in plaats van via het algemene overzicht.

Een custom server voor Next.js. Plesk's Node.js-integratie verwacht een startbestand (traditioneel app.js), maar Next.js heeft dat niet standaard. De oplossing: een eigen, minimale server.js die de Next.js request-handler binnen een Node http-server aanroept en luistert op de poort die Plesk (via Passenger) toewijst.

Permissieproblemen na een mislukte install. Een eerste npm install-poging liep vast op een EACCES-fout — bestanden die eigendom waren van de verkeerde gebruiker, waarschijnlijk overgebleven van een eerdere geautomatiseerde actie. Dat vereiste handmatig ingrijpen via SSH: de kapotte node_modules- en .npm-mappen verwijderen en de eigendomsrechten herstellen met chown.

Een subtiele bijwerking van permissie-herstel. Bij het generiek terugzetten van bestandsrechten (644 voor bestanden) verloren de uitvoerbare scripts in node_modules/.bin — waaronder de next-executable zelf — hun uitvoerrecht. Klein detail, grote impact: de build brak. Opgelost door specifiek de .bin-map weer op 755 te zetten.

Het sluipende dubbele-lockfile-probleem. De meest hardnekkige bug: Next.js detecteerde twee package-lock.json-bestanden (één in de juiste projectmap, één per ongeluk een niveau hoger door een eerdere misconfiguratie) en koos daardoor de verkeerde map als workspace-root. Gevolg: de productie-build werd op de verkeerde plek weggeschreven, en de server kon 'm niet vinden — resulterend in een cryptische "Could not find a production build in the '.next' directory"-foutmelding, en uiteindelijk een Passenger-timeout omdat de app helemaal niet kon opstarten. Pas door het overbodige lockfile te verwijderen en opnieuw te builden, viel alles op zijn plek. Een Node-versieconflict. Zelfs met het juiste pad ingesteld in Plesk, bleek een systeembrede, oudere Node.js-versie (18.x) voorrang te krijgen op de PATH boven de gewenste versie (26.x) wanneer ik commando's handmatig via SSH uitvoerde — makkelijk over het hoofd te zien, en alleen zichtbaar geworden door de foutmelding van Next.js zelf, die een minimale Node-versie afdwingt. Elk van deze problemen was op zichzelf klein, maar samen vormden ze een mooi voorbeeld van hoe deployment op eigen infrastructuur — in tegenstelling tot een kant-en-klaar platform — je dwingt om écht te begrijpen wat er onder de motorkap gebeurt: van bestandsrechten en procesbeheer tot hoe een framework als Next.js zijn eigen workspace-root detecteert.

Resultaat

BezorgFlex draait nu live op bezorgflex.nl, volledig zelf gehost, met een Git-gebaseerde workflow waarmee nieuwe versies met een paar commando's naar productie gaan. Het is op dit moment een prototype/MVP — bedoeld om het concept te valideren bij lokale restaurants, vóórdat verdere stappen worden gezet richting de juridische structuur (WTTA-vergunning, aansluiting bij een uitzend-CAO, een payroll-partner) die nodig is om er een volwaardig uitzendbureau van te maken. Het project laat goed zien dat een sterk idee alleen niet genoeg is: de combinatie van productdenken (hoe bouw je vertrouwen bij een gevoelige doelgroep), juridische zorgvuldigheid (kinderarbeidwetgeving, AVG, arbeidsrecht) én technische uitvoering (van framework-keuzes tot productie-deployment) is wat een concept tot een werkend platform maakt.