Why build your own taxi app when Uber, Bolt and Free Now already exist?
Three reasons. One: with a marketplace, you pay a commission per ride (typically somewhere between 15 and 30 per cent), which structurally erodes your margin. On your own volumes, that quickly exceeds the build and running costs of your own platform combined. Two: the customer base belongs to the marketplace, not to you. If you stop or switch, you lose your repeat customers. Three: a marketplace serves a single workflow: a ride from A to B. Care transport with a Wmo referral, school transport with a pick-up protocol, business transport with cost-centre coding, or contract transport with a monthly consolidated invoice is simply not part of their product. If you run contracted or care transport alongside street work, you can't really do without your own platform.
Does your app integrate with the Boordcomputer Taxi (BCT)?
Yes, an integration with the BCT is non-negotiable for Dutch taxi operators, as it is legally required for order, trip and break registration. We integrate with the existing BCT providers (CMT, Cabbie, EuroCabbie and their variants) via their API or via a data logger in the vehicle. The driver app automatically starts a trip in the BCT when a job is accepted and closes it at final settlement, so the driver doesn't have to operate two screens at once. The trip data is cross-checked against the central system, and discrepancies are flagged for manual review. For those who don't yet have a BCT, we advise which provider best suits your fleet, based on experience.
What about KIWA, the TX Keurmerk and the Wp2000?
The Wet personenvervoer 2000 (Wp2000) and the requirements arising from it, covering the driver's card, BCT registration and the TTO rules in major cities, form the legal basis. For care transport, the CAK quality framework also applies, along with requirements around wheelchair transport and, where relevant, medical assistance. Our app supports document management for the driver's pass, VOG and, where relevant, the TX Keurmerk within the driver onboarding flow, with automatic alerts when a document is about to expire. Legal responsibility remains with the operator, but you get a workspace where you can see the status of every driver and every vehicle in one place.
How does the matching engine work?
At its core, the matching engine combines an ETA calculation (which driver can reach the pickup in how many minutes), a suitability filter (does this vehicle have a wheelchair ramp, a child seat or an executive segment) and a priority layer (which driver has been waiting longest, which is rated higher, which has priority under the client contract). For street transport, it is mainly ETA-driven; for healthcare transport, suitability becomes decisive; for business travel, a specific driver can be linked to each client. For more complex scenarios, we combine it with an
AI development layer that, based on historical trip data, learns when a trip should be dispatched manually rather than automatically, typically where manual overrides keep showing the same patterns.
Which technology do you use?
For the mobile apps, we typically work with Flutter for cross-platform (one codebase for iOS and Android, which reduces maintenance), or go native with Swift and Kotlin if the performance requirements around background tracking and battery impact justify it. For the driver app we often prefer native, because continuous location tracking and background operations are more sensitive there. For the dispatch workstation we build an SPA in React or Vue with a real-time WebSocket connection to the matching engine. For mapping we use Mapbox, HERE or Google Maps Platform; the choice depends on where you operate and what the licence costs do at your volume. The backend runs on Node.js or Go in a container environment (GCP, AWS or Azure), with Postgres as the primary datastore and Redis for real-time state.
How do you handle payments?
For the street segment, we connect by default to Mollie or Adyen, with iDEAL, credit card, Apple Pay and Google Pay as payment methods in the rider app. For business and contracted transport, we work with consolidated invoices per month or per order period, generated from trip records and linked to your invoicing system (Exact, Twinfield, Yuki, AFAS or a custom API). For healthcare transport, claims run through the client portal of the health insurer, the CAK or the municipality; we build the export or the direct integration, depending on what the portal offers. Combinations are common: a operator might receive payment for a street ride in cash or via Mollie, and also send a monthly consolidated Wmo invoice to the municipality at the end of the month.
What about GDPR and data protection?
A taxi platform handles sensitive data: pick-up and drop-off addresses (which can often be traced back to medical situations in patient transport), location history per driver, payment details and, in healthcare transport, indication data. As standard, we carry out a DPIA at the start, provide a data processing agreement template for your clients, and set retention periods in line with GDPR as well as the additional requirements imposed by health insurers. Encryption at rest and in transit is standard, an audit log of sensitive actions is built into the dispatch workstation, and retention periods are enforced in code rather than through a manual procedure.
Can you also build just the dispatch system?
Yes. For some clients the rider and driver apps are the priority, for others the pain lies in the central office, which runs entirely on loose Excel files. We can also build the dispatch system as a standalone SPA that integrates with your existing rider or driver environment, or work in phases: first get dispatch right, then connect the driver app, and only then take the rider app to market. We determine together how to split the project into phases, based on where the greatest losses lie today.
Do you have experience with patient transport specifically?
Yes, patient transport is a key segment in our portfolio. Wmo funding runs through municipalities and the SVB, Valys through Transvision, and seated medical transport through health insurers. Each has its own portal formats, tariff structures and reporting rules. The combination of eligibility checks (is this client actually covered under this contract), co-payment administration, and the strict rules on shared rides (which clients may travel together in one vehicle) is not in standard taxi software. That is typically where we build custom software.
Who owns the code and the data?
You do. We deliver the complete source code, database schemas, build pipelines, deployment scripts, and the App Store and Google Play accounts in your name. The data lives in your cloud or with a hosting partner of your choice. If you later want to work with another agency, or take it in-house, you can: no lock-in on the technology, no percentage of revenue per ride, and no licence fees that grow as you grow. We earn from good work that lasts, not from clients who are locked in.
What determines the cost of such a project?
The biggest cost drivers are: the complexity of the fare engine (a single tariff versus multiple clients with different price lists), the number of integrations (BCT, invoicing, patient transport portals, payment providers), how much matching automation you need versus manual dispatch, and whether several user groups with different flows must be supported (street only versus street plus medical plus business). We work in sprints with a fixed sprint budget, so there are no surprises and you can steer scope sprint by sprint. A scoping conversation gives a good picture of the likely range for your specific case.
How long before we can go live?
A first pilot with a rider app and light dispatch for one segment can be running within a few sprints. A full platform with a driver app, matching engine, BCT integration and multi-client invoicing is a programme of several sprints. We often roll out in phases so part of your fleet can start while we keep building. That gives your organisation room to adapt and gives us feedback we can act on before the next user group. Many large operators deliberately choose a slower rollout to avoid disrupting operations.
