Build a taxi booking system in Bubble with pickup and dropoff location selection on a map, driver matching, fare estimation based on distance, real-time ride status tracking, and payment processing at completion. This tutorial covers the data types, map integration, and workflow logic for a ride-hailing MVP.
Overview: Building a Taxi Booking System in Bubble
This tutorial walks you through building the core features of a taxi booking system in Bubble. You will create data types for rides and drivers, build a map interface for selecting pickup and dropoff locations, implement fare estimation and driver matching workflows, track ride status in real time, and process payment at ride completion. This is ideal for ride-hailing MVPs and transportation startups.
Prerequisites
- A Bubble account with an existing app
- Google Maps API key configured in Bubble settings
- Stripe plugin installed for payments
- Basic understanding of Bubble data types and workflows
Step-by-step guide
Create the ride and driver data types
Create the ride and driver data types
Go to the Data tab and create data types. Ride with fields: rider (User), driver (User), pickup_location (geographic address), dropoff_location (geographic address), status (Option Set: Requested, Accepted, In Progress, Completed, Cancelled), estimated_fare (number), actual_fare (number), distance_km (number), and requested_at (date). Driver with fields: user (User), vehicle_type (text), license_plate (text), is_available (yes/no), current_location (geographic address), and rating (number).
Expected result: Ride and Driver data types exist with all necessary fields.
Build the map-based booking interface
Build the map-based booking interface
Go to the Design tab and create a ride-booking page. Add a Map element and two SearchBox elements (with Google Places integration) for pickup and dropoff addresses. When the user selects addresses, display markers on the map for both locations. Add a text display showing the estimated distance (using the geographic address distance calculation between the two points) and the estimated fare (distance * rate per km). Add a Request Ride button below the fare estimate.
Pro tip: Use Bubble's built-in geographic address distance calculation: Pickup's distance from Dropoff converted to km.
Expected result: Users can search for pickup and dropoff locations, see them on a map, and view the estimated fare.
Create the ride request workflow
Create the ride request workflow
Create a workflow: When Button Request Ride is clicked. Action 1: Create a new Ride with rider = Current User, pickup_location = SearchBox Pickup's value, dropoff_location = SearchBox Dropoff's value, status = Requested, estimated_fare = calculated fare, distance_km = calculated distance, requested_at = Current date/time. Action 2: Show a waiting screen while the system finds a driver. The ride status displays on the page with conditional messaging for each status.
Expected result: A Ride record is created with Requested status and the user sees a waiting state.
Implement driver matching
Implement driver matching
Create a backend workflow called match_driver with parameter ride_id. It searches for Drivers where is_available = yes, sorted by distance from the ride's pickup_location (nearest first). Take the first result and Make changes to the Ride: driver = matched Driver's user, status = Accepted. Make changes to the Driver: is_available = no. If no drivers are found, schedule the same workflow again after 10 seconds (with a max retry count to prevent infinite loops).
Expected result: The system automatically matches the nearest available driver and updates the ride status to Accepted.
Track ride status and complete the ride
Track ride status and complete the ride
On the rider's page, display the ride status with conditional elements: Requested shows Finding your driver, Accepted shows Driver [name] is on the way with vehicle details, In Progress shows Ride in progress with a live map. The driver's interface has buttons to update status: Arrived (change to In Progress), Complete Ride (change to Completed and trigger payment). On completion, calculate actual_fare and trigger the Stripe checkout for the rider. For production ride-hailing apps with real-time GPS and complex routing, consider working with RapidDev.
Expected result: Both rider and driver see live status updates, and payment is processed when the ride completes.
Complete working example
1TAXI BOOKING SYSTEM — WORKFLOW SUMMARY2========================================34DATA TYPES:5 Ride6 - rider (User)7 - driver (User)8 - pickup_location (geographic address)9 - dropoff_location (geographic address)10 - status (Option Set: Requested/Accepted/In Progress/Completed/Cancelled)11 - estimated_fare (number)12 - actual_fare (number)13 - distance_km (number)14 - requested_at (date)1516 Driver17 - user (User)18 - vehicle_type (text)19 - license_plate (text)20 - is_available (yes/no)21 - current_location (geographic address)22 - rating (number)2324FARE CALCULATION:25 base_fare = 2.5026 rate_per_km = 1.5027 estimated_fare = base_fare + (distance_km * rate_per_km)2829WORKFLOW 1: Request ride30 Event: Button Request Ride is clicked31 Action 1: Create new Ride (status = Requested)32 Action 2: Schedule backend workflow match_driver3334BACKEND WORKFLOW: match_driver35 Step 1: Search for Drivers (is_available = yes)36 Sort by: distance from Ride's pickup_location37 Step 2 (driver found): Make changes to Ride38 driver = first Driver's user, status = Accepted39 Step 3: Make changes to Driver (is_available = no)40 Step 4 (no driver): Reschedule in 10 seconds41 Max retries: 6 (1 minute total)4243WORKFLOW 2: Complete ride44 Event: Button Complete Ride is clicked45 Action 1: Make changes to Ride (status = Completed)46 Action 2: Stripe Checkout (actual_fare * 100)47 Action 3: Make changes to Driver (is_available = yes)Common mistakes when building a taxi booking system in Bubble
Why it's a problem: Not resetting the driver's availability after ride completion
How to avoid: Always set is_available = yes on the Driver record when the ride status changes to Completed or Cancelled.
Why it's a problem: Running driver matching on the frontend
How to avoid: Use a backend workflow for driver matching so it runs server-side regardless of the user's connection.
Why it's a problem: Not adding a timeout for ride matching
How to avoid: Add a retry counter parameter and stop matching after a set number of attempts (e.g., 6 retries over 1 minute).
Best practices
- Use backend workflows for driver matching to ensure reliability
- Calculate fares using distance between geographic addresses
- Track ride status with an Option Set for clean conditional logic
- Reset driver availability on ride completion and cancellation
- Add a cancellation workflow for both riders and drivers
- Use the Map element with dynamic markers for pickup, dropoff, and driver location
- Set a timeout on driver matching to avoid infinite loops
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
I am building a taxi booking app in Bubble.io. I need a map-based pickup/dropoff selector, fare estimation, driver matching, real-time ride status, and payment. What data types and workflows do I need?
Build a ride-hailing system. Create Ride and Driver data types. Build a map interface for selecting pickup and dropoff with fare estimation. Implement driver matching as a backend workflow and add status tracking with payment on completion.
Frequently asked questions
Does Bubble support real-time GPS tracking?
Bubble's Map element can display dynamic markers, but real-time GPS tracking with sub-second updates requires a plugin or external service. Bubble's auto-refresh works for updates every few seconds.
How do I calculate distance between two locations?
Use Bubble's built-in geographic address calculations: SearchBox Pickup's geographic address's distance from SearchBox Dropoff's geographic address, then convert to kilometers or miles.
Can I add surge pricing?
Yes. Add a multiplier based on demand — count active Ride Requests in the area and divide by available Drivers. Multiply the base fare by the surge factor.
How does the driver see new ride requests?
The driver's page has a Repeating Group showing Rides where status = Requested and no driver is assigned. Bubble's real-time data refresh shows new requests automatically.
Can RapidDev help build a full ride-hailing platform?
Yes. RapidDev specializes in Bubble development and can help build production ride-hailing apps with real-time GPS, route optimization, surge pricing, and driver management dashboards.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation