Jet ride hailing: from messy brief to 5 user ecosystem

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.

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.