Multi-modal ride-hailing platform for Nigeria and emerging markets. Six user types, one system. I led the product thinking and design end to end, and built the prototypes in code with AI. Some details are obfuscated to respect a client confidentiality agreement.
The Brief Was a Feeling, Not a Product
A client came to me with an early-stage idea: build a ride-hailing platform for Nigeria. The plan, as handed to me, was to compete with Bolt and differentiate on two things, OTP-verified trips and electric vehicles.
There was no business model. No user research. No numbers, no users, no validated demand. Two intended differentiators, and a market already owned by Bolt and Uber.
So the first job was not design. It was working out whether this was a product worth building, and what would actually make it one. The OTP and EV ideas were not a moat. OTP is a feature any competitor can copy in a sprint. EV is mostly a supply-and-financing problem, not a product one. If JET launched on those two ideas alone, it would be a worse-funded clone of an incumbent.
My role was to close that gap. I owned the product thinking and the design across all six surfaces, riders, drivers, fleet owners, hotels, and admins, plus the marketing site. That included the parts a client normally hands a designer already solved: the personas, the competitive position, the business logic, and how the pieces of the system relate. None of that existed. I built it.
The deadline was tight, so the process had to be fast without getting sloppy. I worked the brief into strategy first, using Claude to pressure-test the thinking and rough out prototypes before I touched final screens, then moved into Figma Make to design in code. Brief to strategy to working build, compressed. That workflow is the reason a one-person engagement could produce a six-surface product with the business logic worked out underneath it. The AI-native build is not the headline of this project. It is what let me spend my time on the product decisions instead of on production.
Finding the Real Opening
Before designing a single screen, I tore down the competition to find where the market was actually weak. Not what Uber and Bolt do, but where they fail in Nigeria specifically.
I studied Uber, Bolt, inDrive, and Grab across product, pricing, and trust. The pattern was consistent, and it had nothing to do with OTP or EV:
Driver cancellations are the number one rider complaint. Drivers accept, then cancel when they see a destination that is not profitable. Every cancellation costs the rider five to ten minutes and a lot of goodwill.
Surge pricing is opaque. The price jumps with no explanation, so it reads as punishment, not demand.
Safety is thin, especially for women riding at night.
Vehicle quality is a coin flip. No enforced standard.
The real opening was not a feature. It was trust and reliability. The incumbents had trained Nigerian riders to expect cancellation, price surprises, and uneven safety. A product that fixed those would have a wedge that two copyable features never could.
That reframed everything. OTP and EV did not disappear, they got repositioned. OTP stopped being the headline and became part of a larger trust layer. EV stopped being a green gimmick and became a cost-and-quality story: cheaper rides because electricity beats fuel, and a higher, more consistent vehicle standard because the fleet is newer. The differentiator was no longer "we have OTP and EV." It was "we are the platform you can actually trust to show up, charge fairly, and get you there."
Pricing was a big part of that trust, so I did the fare and surge research myself rather than wait for an engineer to translate the backend. Fare logic is never just math. It changes how confident a rider feels, how they read timing, and whether they judge the product as dependable or as something that punishes them when demand rises. I reasoned through how pricing should communicate, not just compute, so the rider understood why a price was what it was before they ever hit book. Doing that builder's work myself is what let me design pricing as a trust surface instead of a number on a screen.
Designing Against the Cancellation Problem
The clearest expression of the trust wedge was a product decision aimed at the market's most documented failure: show drivers the destination and the fare before they accept a ride.
In Nigeria, this is a live problem, not a solved one. As of early 2026, the market leader still does not show drivers the destination when a request comes in. Drivers see only a rough area, so they accept, then call to ask where you are going, and cancel if the trip does not suit them. The result is the single most common rider complaint in the market: you book, someone accepts, and then you are dropped back into the queue. The incumbents know this hurts, they have been scrambling at it, piloting fare negotiation, broadcasting one request to several drivers at once so the first to accept wins. The problem is real enough that the biggest players are actively reworking their matching to fix it.
JET's answer was informed acceptance. Show the destination and the net fare upfront, so a driver makes one real decision instead of accepting and bailing. If a driver accepts, the rider can trust they are actually coming.
This is not a free win, and I designed for the cost. Showing destinations upfront invites cherry-picking, drivers skipping less profitable routes and leaving some areas underserved. The mitigation was an incentive layer: higher earnings multipliers on routes and times that need supply, surfaced on the driver home screen, plus an acceptance-rate metric so chronic declining has consequences. Informed acceptance for the driver, reliability for the rider, and a lever for the platform to balance supply.
I am not claiming this as an invention. The point is the opposite: I designed JET around the market's actual, documented failure instead of the two features the client walked in with. Knowing that the real fight in Nigerian ride-hailing is over cancellation, matching, and trust, not over OTP or EV, is what made the product decisions land where they mattered.
The Part That Was Actually Mine: What Hotels Do
The brief listed "hotels" as a user type. It did not say what hotels were for. Working that out was the most valuable thing I did on JET, because it was a business model decision disguised as a feature, and I had to make it for two different stakeholders at once.
For the guest, a hotel booking a ride is a trust transfer. A traveler in an unfamiliar city does not trust a new ride-hailing app, but they trust the hotel they are staying in. When the hotel books the ride, the hotel's credibility carries JET. The guest gets a vetted ride without ever having to download an app cold or trust a stranger's brand.
For the business, hotels are a distribution and revenue channel. They bring riders who would never have found JET on their own, high-value travelers, delivered through a partner instead of paid acquisition. The hotel is a customer, a reseller, and a trust intermediary in one relationship.
So I designed the mechanic to match the business reality:
Each hotel runs on a prepaid billing account with credits. When a guest's trip completes, the cost is deducted from the hotel's balance. The hotel is the paying account, which is what makes it a real B2B channel and not just a booking button.
The guest is not left out of the trip. Borrowing the pattern from Bolt's dispatch-sharing, where the person expecting a vehicle can watch it move toward them in real time, I gave the guest live tracking of their ride and the OTP that confirms the trip is complete. The guest monitors and verifies, even though the hotel pays.
The commercial logic for the hotel is margin on the ride plus a concierge-grade perk for high-value guests. The hotel makes money and looks good doing it.
That combination, hotel pays, guest controls and verifies, is what makes the relationship work for everyone. The hotel gets a revenue line and a guest perk. The guest gets a trusted ride they can watch and confirm. JET gets a distribution channel and a paying B2B customer.
The Edge Case the Hotel Model Created
Defining the hotel relationship surfaced a problem a normal two-party ride never has.
In a standard trip, it is the rider and the driver. If something goes wrong, it is between them. But a hotel-booked ride has three parties, the hotel that paid, the guest who rode, and the driver who drove. That raises a question with real money attached: what happens when the trip is disputed? A driver drops a guest short of the destination and marks it complete. Or a guest withholds confirmation so the trip never closes and the driver is not paid against a trip they actually ran.
The guest-held OTP at drop-off is the first line of defense, the trip cannot be marked complete and billed against the hotel's credits until the guest confirms arrival. But the OTP does not resolve a genuine dispute on its own. For that, I routed disputed trip-ends to the JET admin as the arbiter, with the trip data, the live-tracking record, and the OTP status as the evidence. The admin decides, and the resolution flows back to the hotel's billing and the driver's payout.
This is the kind of problem that only appears when you take the business relationships seriously. A designer arranging screens never meets it. A designer defining how the parties relate meets it immediately.
Making the EV Choice Stick
Repositioning EV as cost-and-quality solved the pitch, but not the behavior. A discount alone does not change habits. If I wanted riders to actually keep choosing electric, the choice had to feel rewarding, measurable, and worth repeating.
So I designed the EV layer as behavior change, not a checkbox. Riders get a lower price for choosing an electric vehicle, the immediate incentive. On top of that, I added a gamified carbon-saving score, so the rider sees the impact of their choice accumulate over time. The discount gets them to choose electric once. The visible, growing carbon score gives them a reason to choose it again, and a small sense of progress they own.
That connects the business model to actual behavior. The client wanted EV adoption. Adoption does not come from telling people to go green. It comes from making the green choice the cheaper, more satisfying, more visible one. I designed the product so the social mission and the business incentive pointed the same direction.
Where I Stopped, On Purpose
One question in the hotel model I deliberately did not answer: how the hotel recovers the ride cost from the guest.
There are two clean options, and they trade off against each other. Bundle the ride into the room rate or a service package, which is simpler to bill but makes guests pay for something they may not use. Or offer it as an optional add-on at checkout, which respects consent but lowers the attach rate. The right answer depends on real pricing data and guest behavior, what guests will tolerate, what hotels will push, how it affects margin.
The client had none of that data, and inventing it would have been guesswork dressed up as a decision. So I scoped it as a defined open question for validation rather than a fake answer. Knowing where the idea outruns the evidence is part of the work, especially when you are taking something from a vague brief to a real product without users yet.
What Shipped
JET was a strategy-and-design engagement:
A defined product strategy where there was none, positioned around trust and reliability instead of two copyable features.
The business logic for how six user types relate, including the hotel partnership model that was missing from the brief entirely.
A complete, coherent design system across all six surfaces, built so a fleet owner, a hotel, and a rider all read the same trip through the same visual language.
A developer-ready handoff. I built the prototypes in code (React, via Figma Make) with the routing, components, and key states laid out, so the engineering team had a working reference to build against instead of a static mockup to interpret.
I took an early-stage idea with no model and no research, and handed back a product someone could actually build and defend.
Why This Matters for Mobility and Fleet Operations
The transferable skill here is not "I designed a ride-hailing app." It is this: I am a product designer who takes an underspecified mobility operation, works out how the parties actually relate, commercially and operationally, and designs a system that holds those relationships together. Being AI-native means I can build the prototypes myself to pressure-test that thinking, fast, without waiting on a team.
That is the core problem of fleet and mobility operations. A fleet owner, a driver, the company managing the fleet, and the corporate client are all different parties with different stakes in the same vehicle and the same trip. The value is not in any one dashboard. It is in defining who sees what, who pays whom, who is accountable when something goes wrong, and making the whole system tell one coherent story.
JET is where I learned to do that work, on a brief that gave me nothing but the chance to figure it out.
WANT SOMETHING LIKE THIS?
Every project starts with a conversation. Let's talk about what you're building.