CASE №0003 · Classification: Filed — Operations Concluded
Dryve Africa
Four applications over one vehicle ledger · Drivers, partners, and operations · Ghana
“Vehicle ownership, paid down weekly while the vehicle earns.”
Filing Metadata
- Type
- Software
- Status
- Archived
- Stack
- 4 components
- Filed
- MMXXVI
Filed by the Agent · For Internal Distribution
Owning a vehicle in Ghana usually means paying cash upfront. That single sentence decides who gets to earn a living driving and who rents from someone who did. The driver who most needs the vehicle — because it is the instrument of the work, not a convenience — is precisely the one who cannot produce the lump sum.
Dryve financed vehicle ownership through structured hire-purchase, paid down weekly while the vehicle earned. But a lending book needs capital before it can lend, so the system had to serve two populations at once: drivers who needed a car, and partners willing to fund one — with a vehicle they already owned, or with cash. Matching those two sides, and keeping the ledger honest between them, is the actual product.
I built the whole thing: the marketing site, the Dryver dashboard, the Partner dashboard, and the admin console operations ran the business from. Three role-specific applications over one shared ledger, described below in the order a vehicle moves through them.
The Bureau notes that hire-purchase was not invented here. Only, apparently, applied to the people who needed it most.
Chapter A · Public Site
Where the pitch has to land in one line.
The front door had to explain an unfamiliar arrangement to two audiences at once without reading like a loan document. It settles on one promise — get a car, get empowered; own a car and make a living at a flexible pace — and then answers the three questions everyone actually asks: what does it cost, how do I pay, and who do I call when something breaks. Registration splits from here into the two role-specific applications behind it.
Exhibit A · Public Site · Hero
Marketing site · sign-in · registration
- ◆One promise up front, three objections answered below it
- ◆Weekly instalments stated plainly, not buried in terms
- ◆Registration forks into Dryver and Partner sign-up
Chapter B · Dryver Dashboard
When a driver has no car yet, and then does.
The Dryver dashboard has two entirely different jobs depending on whether a vehicle has been assigned. Empty, it is an application: personal details, contact, driving history — how long they have held a licence, whether they have driven for Bolt or Uber — and the type of car they want. That driving-history block is the underwriting input; it is the closest thing to a credit file for someone who has never had one. Once a vehicle is assigned the same route becomes a payment view: cost of car, paid to date, amount left, the specs of the car they are driving, and a button to make this week's payment.
Exhibit B · Dryver · Request a Vehicle
Request a vehicle · then track paying it off
- ◆Same route, two states — application before assignment, ledger after
- ◆Licence tenure and ride-hailing history as underwriting inputs
- ◆Cost / paid / outstanding in GHS, always visible
- ◆Weekly payment and full payment history per driver
Chapter C · Partner Dashboard
When someone else's capital buys the car.
Partners are the supply side: people who put a vehicle into the fleet and earn as it is paid down. They can partner two ways — contribute a car they already own, or contribute capital — and the intake form branches on that choice, asking for make, model, year, and registration status only when an actual vehicle is involved. Their home view is a portfolio: expected return against amount invested, return realised so far, outstanding across the fleet, and every vehicle they own with the Dryver currently driving it named underneath.
Exhibit C · Partner · Fleet Overview and Returns
Fund a vehicle with a car or with capital
- ◆Partner with a car or with capital — the form branches on it
- ◆Expected return, realised return, and outstanding across the fleet
- ◆Every vehicle names the Dryver currently driving it
- ◆Car-details fields appear only for vehicle partnerships
Chapter D · Admin Console
When someone has to decide, and keep the ledger.
Both sides of the marketplace apply, and someone at Dryve has to say yes or no. The console is built around that: a Requests queue tabbed between Dryvers and Partners, each row approving or rejecting inline, with Approved and Rejected as their own destinations so a decision is never lost. Past the queue is the fleet — every car with its assignee, contact, and a ring showing how much of it has been paid off — and behind each car a full record: which Dryver holds it, cost, paid, outstanding, specs, and their complete payment history.
Exhibit D · Admin · Approvals Queue (Dryvers / Partners)
Approvals queue · fleet · per-vehicle ledger
- ◆Approve/reject inline, tabbed across both applicant types
- ◆Requests → Approved → Rejected as durable states, not a filter
- ◆Fleet grid with per-vehicle payoff progress at a glance
- ◆Per-vehicle record ties car, Dryver, and payment history together
How the System Holds Together · A Brief Explanation
Three dashboards, one vehicle record, one source of truth.
The hard part of this system is not any single screen. It is that the same vehicle appears in three applications at once and must say the same thing in all of them. To the Dryver it is a car they are paying off. To the Partner it is capital earning a return. To Admin it is a row in the book with an assignee and an arrears position. One record, three vocabularies.
So the vehicle is the primitive, not the user. Every car carries its cost, its assigned Dryver, its funding Partner, and its payment history; each dashboard is a projection of that record through the lens of whoever is looking. A payment posts once and moves three numbers — the Dryver's amount left, the Partner's realised return, and the fleet's outstanding — because they are all reading the same underlying figure rather than keeping separate tallies that drift.
Around that sits the approvals flow, which is what makes the marketplace safe: nobody enters the ledger without a decision. What each surface is responsible for:
Public site
explains the arrangement · routes sign-up by role
Dryver dashboard
vehicle request, then payment ledger once assigned
Partner dashboard
fund by car or capital · track return and outstanding
Admin approvals
approve or reject Dryvers and Partners before entry
Admin fleet
every vehicle, assignee, and payoff progress
Vehicle record
the shared primitive all three dashboards project
Payment history
one posting, reflected consistently in every view
The reward for getting the shared record right is that nobody has to reconcile anything by hand — the driver, the partner, and the operator are looking at the same number from three directions.
Parts Inventory · Annotated by the Agent
- Frontend
- Next.js · TypeScript
- Backend
- Python
- Database
- MongoDB
- Applications
- Public site · Dryver · Partner · Admin
- Repayment
- Weekly instalments · GHS
- Role
- Whole system, front to back
- Market
- Ghana
“One car, three dashboards, and everybody reading the same number from a different direction.”
— Internal memo, undated
Source materials and binaries withheld pending review.