Waarom een eigen taxi-app als Uber, Bolt en Free Now al bestaan?
Drie redenen. Eén: bij een marketplace betaal je een commissie per rit (typisch ergens tussen 15 en 30 procent) die je marge structureel verlaagt — bij eigen volumes wordt dat snel meer dan de bouw- en beheerkosten van een eigen platform bij elkaar. Twee: je klantenbestand is van de marketplace, niet van jou. Stoppen of overstappen betekent het kwijtraken van je herhaal-klanten. Drie: een marketplace bedient één werkstroom — een rit van A naar B. Zorgvervoer met Wmo-indicatie, leerlingenvervoer met afhaal-protocol, zakelijk vervoer met kostencentra-codering, of contract-vervoer met verzamelfactuur per maand zit niet in hun product. Wie naast het straat-segment ook gecontracteerd of zorg-vervoer doet, kan eigenlijk niet zonder een eigen platform.
Werkt jullie app met de Boordcomputer Taxi (BCT)?
Ja, koppeling met de BCT is voor Nederlandse taxi-vervoerders niet onderhandelbaar — het is wettelijk verplicht voor opdracht-, rit- en pauze-registratie. Wij koppelen met de bestaande BCT-leveranciers (CMT, Cabbie, EuroCabbie en hun varianten) via hun API of via een datalogger in de auto. De driver-app start automatisch een rit in de BCT bij job-acceptance en sluit hem af bij eind-afrekening, zodat de chauffeur niet twee schermen tegelijk hoeft te bedienen. De ritgegevens worden cross-gecheckt met de gegevens in de centrale, en afwijkingen worden geflagd voor handmatige controle. Voor wie nog geen BCT heeft adviseren we welke leverancier het beste bij je vloot past — daar zit ervaring achter.
Wat met KIWA, TX-Keurmerk en de Wp2000?
De Wet personenvervoer 2000 (Wp2000) en de daaruit voortvloeiende eisen voor de chauffeurskaart, de BCT-registratie en de TTO-regels in grote steden zijn de juridische basis. Voor zorgvervoer komt daar het kwaliteitskader van het CAK bij, plus eisen rond rolstoelvervoer en eventueel medische assistentie. Onze app ondersteunt het document-management voor chauffeurspasje, VOG en eventueel TX-Keurmerk binnen de driver-onboarding-flow, met automatische signalering wanneer een document bijna verloopt. De juridische verantwoordelijkheid blijft bij de vervoerder, maar je krijgt een werkruimte waarin je op één plek de status van iedere chauffeur en iedere auto kunt zien.
Hoe werkt de matching-engine?
De matching-engine is in de kern een combinatie van een ETA-berekening (welke chauffeur kan over hoeveel minuten bij de pickup zijn), een geschiktheids-filter (heeft deze auto een rolstoeloprijplaat, een kinderzitje, een executive-segment) en een prioriteits-laag (welke chauffeur staat al langer stil, welke is hoger gewaardeerd, welke heeft prioriteit volgens het opdrachtgever-contract). Voor straat-vervoer is het vooral ETA-gedreven, voor zorgvervoer wordt geschiktheid bepalend, voor zakelijk vervoer kan een specifieke chauffeur per klant gekoppeld zijn. Voor complexere scenario's combineren we hem met een
AI-ontwikkelingslaag die op basis van historische ritdata leert wanneer een rit handmatig dispatched moet worden in plaats van automatisch — typisch waar handmatige overrides keer op keer dezelfde patronen laten zien.
Welke technologie gebruiken jullie?
Voor de mobiele apps werken we typisch met Flutter voor cross-platform (één codebase voor iOS en Android, scheelt onderhoud) of native met Swift en Kotlin als de prestatie-eisen rond background-tracking en battery-impact dat rechtvaardigen. Voor de driver-app gaat onze voorkeur vaak naar native, omdat continue location-tracking en background-operations daar gevoeliger liggen. Voor de dispatch-werkplek bouwen we een SPA in React of Vue met real-time websocket-koppeling naar de matching-engine. Mapping doen we met Mapbox, HERE of Google Maps Platform — keuze hangt af van waar je rijdt en wat de licentiekosten doen op jouw volume. Backend draait op Node.js of Go in een container-omgeving (GCP, AWS of Azure), met Postgres als primary datastore en Redis voor real-time state.
Hoe regelen jullie de betalingen?
Voor het straat-segment koppelen we standaard aan Mollie of Adyen, met iDEAL, creditcard, Apple Pay en Google Pay als betaalmethoden in de rider-app. Voor zakelijk en contracted vervoer werken we met verzamelfacturen per maand of per opdracht-periode, gegenereerd vanuit de ritregistratie en gekoppeld aan je facturatie-systeem (Exact, Twinfield, Yuki, AFAS of een eigen API). Voor zorgvervoer loopt de declaratie via het opdrachtgever-portaal van de zorgverzekeraar, het CAK of de gemeente — wij bouwen de export of de directe koppeling, afhankelijk van wat het portaal aanbiedt. Combinaties komen veel voor: een vervoerder kan een straat-ritje contant of via Mollie krijgen en daarnaast aan het einde van de maand een Wmo-verzamelfactuur naar de gemeente sturen.
Wat met AVG en gegevensbescherming?
Een taxi-platform verwerkt gevoelige gegevens: pickup- en dropoff-adressen (regelmatig medisch herleidbaar bij ziekenvervoer), location-history per chauffeur, betalingsgegevens, en in zorgvervoer indicatie-gegevens. Wij doen standaard een DPIA bij de start, leveren een verwerkingsovereenkomst-template voor jouw opdrachtgevers, en regelen retentie- en bewaartermijnen volgens AVG én de aanvullende eisen die zorgverzekeraars stellen. Encryption-at-rest en in-transit zijn vanzelfsprekend, een audit-log op gevoelige acties zit standaard in de dispatch-werkplek, en bewaartermijnen worden afdwingbaar in code, niet in een handmatige procedure.
Kunnen jullie ook alleen het dispatch-systeem bouwen?
Ja. Voor sommige klanten is de rider- en driver-app prioriteit, voor anderen ligt de pijn in de centrale die volledig op losse Excel-bestanden draait. We kunnen het dispatch-systeem ook als losse SPA bouwen die koppelt met je bestaande rider- of driver-omgeving, of in fasen werken: eerst dispatch netjes, daarna driver-app erop aansluiten, daarna pas de rider-app naar de markt. Hoe het traject in fasen wordt geknipt bepalen we samen op basis van waar het meeste verlies zit vandaag.
Hebben jullie ervaring met zorgvervoer specifiek?
Ja, zorgvervoer is een belangrijk segment in onze portefeuille. Wmo via gemeenten en SVB, Valys via Transvision, zittend ziekenvervoer via zorgverzekeraars — elk heeft eigen portaal-formaten, eigen tarief-structuren en eigen verantwoordingsregels. De combinatie van indicatie-controle (mag deze klant eigenlijk gereden worden onder dit contract), eigen-bijdrage-administratie, en de strikte regels rond combinatie-ritten (welke klanten mogen samen in één auto) zit niet in standaard taxi-software. Daar bouwen we typisch maatwerk voor.
Wie is eigenaar van de code en de data?
Jij. Wij leveren de volledige source code, database-schema's, build-pipelines, deploy-scripts en het App Store- en Google Play-account op jouw naam. De data leeft in jouw cloud of bij een hosting-partij naar jouw keuze. Als je later met een ander bureau verder wilt, of intern wilt overnemen, kan dat — geen lock-in op de techniek, geen omzet-percentage per rit, geen licentiekosten die meegroeien als jij groeit. Wij verdienen aan goed werk dat blijft, niet aan klanten die vastzitten.
Wat bepaalt de kosten van zo'n traject?
De grootste kostendrijvers zijn: de complexiteit van de fare-engine (één tarief versus meerdere opdrachtgevers met afwijkende prijslijsten), het aantal koppelingen (BCT, facturatie, zorgvervoer-portalen, betaal-providers), de mate waarin je matching-automation nodig hebt versus handmatige dispatch, en of er meerdere doelgroepen met verschillende flows moeten worden ondersteund (alleen straat versus straat plus zorg plus zakelijk). We werken in sprints met een vast sprintbudget, zodat je niet voor een verrassing komt te staan en je per sprint kunt sturen op scope. Een richtgesprek over scope geeft een goed beeld van de bandbreedte voor jouw specifieke geval.
Hoe lang voor we live kunnen?
Een eerste pilot met rider-app en lichte dispatch voor één segment kan binnen een paar sprints draaien. Voor een volledig platform met driver-app, matching-engine, BCT-koppeling en multi-opdrachtgever-facturatie rekenen we een traject van meerdere sprints. We rollen vaak gefaseerd uit zodat één deel van je vloot al kan starten terwijl wij doorbouwen — dat geeft de centrale ruimte om te wennen en levert ons feedback op die we direct verwerken voor de volgende doelgroep. Veel grote vervoerders kiezen bewust voor een tragere uitrol om operationele verstoring te vermijden.
