Trying to figure out what it actually costs to build a two-sided ride-hailing marketplace -- and getting wildly different answers from different vendors?
Not sure whether to start with a full app or an MVP that proves demand in one city before you scale?
How to Build an App Like Rapido
Rapido proved that two-wheeler ride-hailing is a real business. Bike taxis are faster, cheaper, and better suited to urban traffic than four-wheelers in many cities. If you want to build a platform for bike taxis, auto-rickshaws, cargo bikes, or last-mile logistics in a specific city or region, this guide is for you.
We build ride-hailing and logistics platforms for founders targeting specific modes of transport or geographic markets. This page covers what the core platform needs, what it costs, and how we approach these projects.
Rider app and captain app -- two separate mobile apps with the right UX for each user type
Real-time matching engine that pairs riders with the nearest available captain in seconds
GPS tracking with live map, ETA updates, and route navigation for captains
Dynamic pricing, fare calculation, in-app payments, and wallet management
Building a ride-hailing app like Rapido costs $80,000--$180,000 and takes 14--24 weeks for the core platform. The key components are a rider app, a captain (driver) app, a real-time matching engine, GPS tracking, dynamic pricing, and an integrated payment and wallet system.
100+Products shipped
·24+Industries served
·FixedCost delivery
·12-14Week delivery cycles
Why the ride-hailing market is worth entering
Two-wheeler ride-hailing is growing faster than car-based ride-hailing in dense urban markets across South and Southeast Asia, Latin America, and parts of Africa. Bikes navigate traffic faster, cost less per trip, and serve the majority of daily commuters who don't need a car. Rapido reached 25 million users in India before it was eight years old. The market is large and the category is still early in most cities outside major metros.
The opportunity for a new entrant is not to beat Rapido nationally. It is to serve a specific city, region, or transport mode that larger platforms underserve. A local operator who knows the city, the captain community, and the commuter behavior has real advantages over a platform spreading thin across hundreds of cities. Regional language support, locally trusted payment methods, and captain onboarding relationships matter more than brand scale at the city level.
Last-mile logistics is a parallel opportunity. Cargo bikes and two-wheelers are the most efficient way to move small parcels, food orders, and documents in dense urban areas. A platform built for freight on two wheels serves a different use case from passenger ride-hailing but uses most of the same core technology: real-time dispatch, GPS tracking, proof of delivery, and payments.
What makes Rapido work
Rapido's core insight was pricing and speed. Bike trips cost roughly half of auto-rickshaw trips for the same distance, and the actual journey time is faster in traffic. For a commuter making ten trips a week, that saving compounds. Rapido built a product that was cheaper and faster than every alternative -- that is a strong enough value proposition to drive adoption without needing network effects to kick in.
The captain experience matters as much as the rider experience. Captains are independent workers choosing between platforms. Rapido wins captain supply by making earnings predictable and the app simple to use. Low friction onboarding, clear earnings dashboards, and an app that works on low-end Android devices are part of the product, not afterthoughts.
Core features you need to build
Real-time matching algorithm
The matching engine is the heart of any ride-hailing platform. It takes an incoming ride request and finds the best available captain within a defined radius, considering distance, ETA, and captain acceptance rate. The algorithm needs to work within two to three seconds or riders abandon the request.
For a new platform, the matching logic does not need to be as complex as Uber's system. A well-designed nearest-available dispatch works fine for early-stage operations with predictable demand patterns. Complexity grows as you add surge pricing zones, captain preference rules, and multi-stop trips. Build for today's volume but architect so the matching engine can be replaced as you grow.
The business value is low cancellation rates and short wait times. Both directly affect rider retention. A rider who waits eight minutes twice in a row tries a competitor the third time.
Captain (driver) app
Captains need a separate app from riders. The UX is different: captains are working, often riding, and need large tap targets, audio alerts for new requests, and a minimal number of taps to accept a ride. The app must work reliably on low-end Android devices with intermittent connectivity, which is the reality for most captains in emerging markets.
Key screens include the online/offline toggle, incoming ride requests with rider location and trip distance, navigation integration (Google Maps or a local alternative), trip completion and payment confirmation, and the earnings dashboard. The earnings dashboard is important for captain retention -- captains who can see their daily and weekly earnings clearly are less likely to switch platforms.
Push notification reliability is critical. A captain who misses three ride requests because of a notification delay loses earning time and gets frustrated. The notification stack needs to be tested on the devices and networks your captains actually use.
Rider app
The rider app needs to do one thing fast: show available captains nearby and let the rider book in under thirty seconds. The home screen is a map with the rider's location, a destination input, an estimated fare, and a book button. Everything else is secondary.
Beyond booking, the rider app handles live trip tracking with the captain's position on the map, ETA countdown, trip summary with fare breakdown, rating the captain, and payment history. Safety features -- sharing the trip with a contact, an SOS button -- are now standard expectations in most markets and affect app store approval in some regions.
Registration and onboarding should require as little friction as possible. Phone number plus OTP is the right pattern for emerging markets. Email registration adds a step that reduces conversion.
GPS tracking and navigation
Live GPS tracking serves three purposes. Riders can see the captain moving toward them, which reduces support contacts asking "where is my driver." Captains get turn-by-turn navigation to the pickup and drop-off without leaving the app. Your operations team can see the full fleet on a map for monitoring and dispute resolution.
Location polling frequency is a technical decision with cost implications. Polling every two seconds gives a smooth experience but increases battery drain and server costs. Every five seconds is a reasonable starting point. The location data also feeds your analytics -- you can see which corridors have the most rides, where captains cluster when idle, and where coverage gaps exist.
Integration with a mapping provider (Google Maps, Mapbox, or a regional provider) covers navigation. Building your own mapping is not worth it. The cost is in API calls, not the integration.
Dynamic pricing and fare calculation
Fare calculation needs to be transparent and predictable. Riders should see the fare estimate before they book, and the final fare should match it unless the route changed significantly. Surprise fares are the leading cause of one-star reviews for ride-hailing apps.
Dynamic pricing (surge pricing) applies a multiplier to base fares during peak demand periods -- morning commute, evening rush, rainy days when demand spikes. The multiplier increases captain earnings during surge, which brings more captains online, which reduces wait times. The rider sees the multiplier clearly before booking and can choose to wait or pay.
Fare calculation components: base fare, per-kilometer rate, per-minute rate for time in traffic, minimum fare, and surge multiplier. Night surcharges and toll handling are additions for later. Keep the formula simple to start.
Payments, wallet, and settlements
Payment options need to match local behavior. In India, UPI is the primary digital payment method. In Southeast Asia, GrabPay or local wallets dominate. In Latin America, cash still accounts for a large share of trips. Your payment stack needs to support the methods your market uses, not just credit cards.
An in-app wallet lets riders preload credit and pay instantly without entering payment details for each trip. Wallets also allow you to issue promotional credits, referral bonuses, and refunds easily. Captain payouts need to be automated -- weekly or daily settlements to the captain's bank account or wallet, with a breakdown of trips, fares, and any platform commission deducted.
Payment disputes are inevitable. Build a clear dispute resolution flow for riders and captains from the start. Manual dispute resolution at scale is expensive.
Ratings and safety features
Mutual ratings -- riders rate captains, captains rate riders -- create accountability on both sides. Low-rated captains get fewer ride requests. Low-rated riders may be declined by captains. The rating system needs to be simple (one to five stars plus optional comments) and the results need to affect dispatch in a visible way for the system to have credibility.
Safety features are a legal and reputational requirement, not optional. An SOS button that alerts a predefined contact with the rider's location and trip details is the minimum. Some markets require integration with local emergency services. Trip sharing (sending a live tracking link to a contact) is widely expected. For women's safety, some operators run a women-only mode that matches female riders with female captains.
Captain verification is a safety feature for riders and a regulatory requirement in many markets. Background check integration, license verification, and vehicle registration checks need to be part of the captain onboarding flow.
Business model options
The standard ride-hailing model is a commission on each trip: the platform takes 15--25% of the fare, and the captain receives the rest. This is simple to implement and aligns platform revenue with GMV. At early stage, commission rates can be lower to attract captains; the rate increases as the platform's value to captains (ride volume) justifies it.
Subscription models for captains are becoming more common. Instead of per-trip commission, captains pay a fixed weekly or monthly fee for access to the platform and receive 100% of each fare. This is attractive to high-volume captains who work full-time and predictable for platform revenue forecasting. Rapido introduced a captain subscription plan alongside its commission model.
Advertising and partnerships add a third revenue stream once you have meaningful rider volume. Brands pay to show offers in the app -- fuel discounts, food delivery credits, financial products for captains. This revenue is small at early stage but meaningful at scale. For a regional operator, a partnership with a local fuel network or insurance provider can generate revenue and captain loyalty simultaneously.
What RaftLabs builds for you
Rider and captain mobile apps
We build native iOS and Android apps for both riders and captains, or React Native apps if a shared codebase is the right choice for your budget and team. The rider app covers booking, live tracking, payments, and history. The captain app covers ride acceptance, navigation, earnings, and status management.
Both apps are built to work reliably on mid-range and low-end devices with intermittent mobile data. We test on real devices, not just simulators, because the difference matters for the markets these apps serve.
Real-time dispatch backend
The dispatch engine handles the real-time matching logic, location updates, and trip state management. We use WebSockets for live communication between the rider app, captain app, and server -- this is what makes location updates and ride status changes appear instantly rather than after a polling delay.
The backend is designed to scale horizontally. A platform starting in one city with a few hundred captains has different load characteristics from a platform running in ten cities with ten thousand captains. We architect for growth from the start without over-engineering for day one.
Operations dashboard
Your operations team needs a web dashboard to monitor live trips, manage captain accounts, handle disputes, configure pricing zones, and run reports. This is not a nice-to-have -- your support team will use this daily from day one.
The dashboard includes a live map of active trips and available captains, captain verification queue, trip dispute resolution tools, pricing zone configuration, and financial reporting. Access control lets you give different roles to support agents, finance, and operations managers.
Payment integration and captain settlements
We integrate with the payment providers your market uses -- Razorpay, Stripe, PayU, or regional wallets and UPI. The integration covers rider payments, wallet top-ups, and promotional credits. Captain settlement automation runs on a configurable schedule, calculating each captain's earnings, deducting platform commission, and triggering the payout.
Payment reconciliation reporting gives your finance team a clear view of collected fares, platform commission, refunds, and captain payouts by day, week, and month.
Analytics and growth tooling
We build a reporting layer that shows you the metrics that matter for a ride-hailing business: average wait time, acceptance rate, cancellation rate, captain utilization, and GMV by zone. These numbers tell you where the platform is working and where it needs attention.
Promo and referral mechanics -- discount codes, first-ride offers, refer-a-friend credit -- are part of the standard build. Growth tools are most effective when they are built into the product from the start rather than added as an afterthought six months in.
Frequently asked questions
A core ride-hailing platform with a rider app, captain app, dispatch backend, payments, and operations dashboard typically costs $80,000--$180,000. The lower end covers a focused MVP for one city with a single transport mode. The higher end covers multi-city launch, multiple vehicle categories, advanced surge pricing, and captain subscription billing.
The biggest cost drivers are the number of platforms (iOS, Android, web), the complexity of the matching and pricing logic, the payment provider integrations required, and the scope of the operations dashboard. A React Native shared codebase reduces mobile development cost compared to separate native apps. We scope every project before pricing -- fixed cost, agreed before development starts.
A focused MVP covering the core booking flow, real-time tracking, and payments takes 14--18 weeks from kick-off to launch. A full platform with captain subscription billing, surge pricing, promotional tools, and a complete operations dashboard takes 20--28 weeks. These timelines assume a clear scope agreed at the start and no major scope changes during development.
Regulatory approval for captain onboarding and payment processing varies by market and can affect your launch timeline independently of development. We recommend starting the regulatory process in parallel with development, not after.
Real-time reliability at scale is the hardest challenge. A matching engine that works for 50 concurrent requests behaves differently when there are 5,000. Location data flooding the server from thousands of active captains requires a different architecture from a small pilot. The WebSocket connection management, location data processing, and matching logic all need to be designed with scale in mind from day one, even if you are not starting at scale.
The second hardest challenge is offline and low-connectivity handling. Captains in the field lose connectivity. The app needs to handle reconnection gracefully, not lose in-progress trip data, and catch up when the connection returns.
Separate apps are the right choice in almost every case. The UX requirements for riders and captains are different enough that a combined app adds complexity without adding value. Riders want a simple, fast booking experience. Captains need a high-contrast, easy-to-tap interface designed for use while wearing a helmet and gloves. Separate apps also give you separate app store listings, separate review management, and the ability to update each app independently.
A shared codebase (React Native) can reduce development cost while still producing separate apps with different interfaces. This is the most common approach for cost-sensitive projects.
In India, ride-hailing aggregators are regulated by state transport departments under the Motor Vehicles (Amendment) Act 2019. Requirements include driver background verification, vehicle fitness certification, route-neutral fares, grievance redressal mechanisms, and data localization for certain data types. Requirements vary by state, and some states require a separate aggregator license.
In Southeast Asia, requirements vary by country. Most markets require local entity registration, driver licensing compliance, and integration with local payment systems. Some markets -- Vietnam, for example -- have specific regulations on ride-hailing pricing and driver-passenger ratios.
We work with legal counsel in the relevant jurisdictions to ensure the platform architecture supports compliance requirements. The compliance work is separate from development but closely connected to it.
