You can build a good booking app and still have nobody to send when a customer requests a ride.
That is the awkward part of starting an e-hailing business as a solo developer. The map works. Payments work. You have spent weeks getting the pickup flow right. But before anyone can use it, you need drivers who will actually turn up.
You could recruit them yourself. Find car owners, speak to fleet operators, work out who covers which area and start taking bookings. You do not have to own the vehicles, but you do have to organise the supply behind your app. That can quickly become the bigger job.
Relay gives you a way to build around an existing driver network. It provides logistics as a service: your backend requests a task through the API, and Relay coordinates matching and task progress. You build the app your customers use. E-hailing is one use case for that infrastructure, rather than a passenger service operated by Relay itself.
What running your own fleet involves
Say you want to launch in one part of Lagos. Before you can promise customers a pickup, there is quite a bit to arrange:
- Recruitment. Find drivers or fleet partners, agree on earnings and explain why they should join a new service with few customers.
- Verification. Check identities, licences and vehicle documents; arrange appropriate background checks with consent. Keep track of documents that need renewing.
- Vehicle checks. Assess condition, maintenance and suitability. You need to know which vehicles are ready for work, not just how many are registered.
- Onboarding. Teach drivers how requests, pickups, cancellations and support work. Agree on the service customers should expect.
- Daily coverage. Plan for busy hours, drivers going offline and vehicles breaking down. Someone has to deal with the gaps.
- Local access. Build relationships around estates, campuses, terminals and pickup points. Work out the operating requirements for your service.
- Support and payments. Handle missed pickups, disputes, incidents and settlements. Follow up on recurring complaints.
Then you want to expand. A launch in another state means finding reliable local partners and working through much of that list again. Meanwhile, customers are still asking for improvements to the app.
For a solo developer, this is a serious constraint on how much you can build and how far you can reach.
Connect the booking flow to Relay
With Relay, your backend sends the pickup, destination and task requirements through an API. Your app can use task events and location updates to show what is happening: waiting for a driver, assigned, on the way or completed.
That leaves more time for the details customers notice. Can they place the pickup pin outside the right gate? Can they book without calling for help? Is it clear what happens when no driver is available?
An example app screen with simulated driver locations.
You can test that experience before arranging a live launch. Relay's test mode gives you simulated drivers, so you can work through the booking and tracking flow without assembling a fleet just to try your idea.
You still run your customer-facing business. Support, pricing and the responsibilities of a passenger service remain yours to organise. Before launch, agree with Relay on driver supply, verification standards and the operating arrangements for your service. Relay currently describes its coverage as a Lagos and Abuja pilot; confirm your launch area and vehicle requirements with the team.
Cars, kekes or motorcycles
Your product does not have to look like every other booking app. You might want a car service for a particular community, a keke booking app for short local journeys, or a motorcycle service where passenger operations are permitted.
Relay lets your backend specify the vehicle category for a task:
| Your app | API vehicle preference |
|---|---|
| Car bookings | CAR |
| Keke bookings | TRICYCLE |
| Motorcycle bookings | MOTORCYCLE |
For an SUV service, discuss the required vehicles with Relay. There is no separate SUV category in the current API, so selecting CAR alone would not guarantee one. Each service also needs suitable supply in its launch area.
If you want to work with particular fleet partners, you can specify allowedOrganisations and set allowIndependentRiders: false. Your app can then match within that selected group. The matching documentation covers these controls.
This makes it easier to try different products through the same integration, without personally starting another recruitment operation for each one.
Try a booking from your backend
Here is a Node.js request for a simulated passenger task. Use a Relay test key; this example does not book a real driver.
import { RelayClient } from '@relay-sdk/sdk-node';
const apiKey = process.env.RELAY_API_KEY;
if (!apiKey?.startsWith('sk_test_')) {
throw new Error('Use a Relay test key for this example');
}
const relay = new RelayClient({ apiKey });
const { task } = await relay.tasks.create({
taskType: 'PASSENGER_RIDE',
preferences: { vehicleType: ['CAR'] },
stages: [
{
type: 'PICKUP',
instructions: 'Simulation only',
location: {
latitude: 6.4541, longitude: 3.4246,
address: 'Demo pickup, Ikoyi, Lagos',
},
passengers: [{ name: 'Demo passenger', luggageCount: 0 }],
},
{
type: 'DROPOFF',
instructions: 'Simulation only',
location: {
latitude: 6.4474, longitude: 3.4495,
address: 'Demo destination, Ikoyi, Lagos',
},
},
],
autoAssign: true,
paymentMethod: 'WALLET',
simulationOutcome: 'SUCCESS',
}, { idempotencyKey: 'ride-demo:booking-001:attempt-1' });
console.log(task.id, task.status);
Keep the API key on your server and save the returned task ID against the booking. Reuse the same request and idempotency key when retrying that booking attempt; use a new key for a new booking.
Next, connect verified webhooks to your backend and a task-scoped WebSocket subscription to your UI. Try cancellations and the no-driver outcome as well as a successful booking. If you show a price before dispatch, request a quote first and create the task before it expires.
You now have something you can build a product around. Relay also has browser and Flutter tooling for the customer-facing part of the app.
What could you build beyond the first city?
Access to a shared network changes the expansion question. As Relay adds drivers and supported areas, you can explore those markets through the integration you already have, instead of beginning every launch by finding and onboarding another fleet yourself.
There are opportunities beyond passenger bookings, too. Within a state, a retailer could arrange pickups from several shops and deliveries to customers through one app. Across states, a business could let sellers request transport to customers or collection points along supported routes. Both depend on suitable vehicles and confirmed route coverage, but the developer can build the ordering, booking and tracking experience around the same task API.
That is the appeal of adopting Relay early: you can start with a focused local product and expand what it does as the network grows. E-hailing is the example here. We will cover other apps you can build with Relay in upcoming posts.
Get a test key and explore Relay · Read the API docs
Map: OpenFreeMap / OpenMapTiles, © OpenStreetMap contributors (ODbL).















