Product strategy · Experience design · Implementation

Designing a clearer way to import a car.

Importing a car from the United States to Nigeria involves far more than shipping. There is buying, trucking, port handling, documents, customs and delivery. I worked with My Car Importer to bring that process into one product for the team—and make it much easier for customers to follow.

Role: Product design + full-stack engineering
Product: Operations ERP + customer portal
Platform: Responsive web
Scope: 0 → 1, then V2 expansion

A car changes hands several times before it reaches its owner.

The challenge

The team knew the process. Their tools did not.

Much of the work lived across spreadsheets, documents and conversations. Staff had to keep track of vehicles, trucking jobs, containers and customer updates across different places. Small gaps in information created more calls, more follow-ups and more room for mistakes.

Customers experienced the same problem from the other side. Once they had paid, they still needed to ask where their car was, whether a document had arrived or what came next. My job was to make the process legible without pretending it was simple.

The product strategy

One service needed two very different products.

For the team

Operations ERP

The working side of the service. I designed and built the tools for orders, trucking, containers, documents, invoices, alerts and operational exceptions.

For customers

Customer portal

The customer side. I built quoting, order requests, wallet funding, auction bids, documents and tracking around the same underlying order data.

Operations teamThe same order recordCustomer

How I built it

A thin frontend over a strong data layer.

I built both products as responsive, multi-page web applications. Supabase handles authentication, Postgres, file storage and server-side functions; Vercel handles the static deployments. The browser stays focused on interaction while permissions, financial rules and integrations run behind it.

HTML
CSS
JavaScript
Supabase
PostgreSQL
Edge Functions
Vercel
Resend

Operations ERPSupabase + PostgresCustomer portal

Experience architecture

Not every car takes the same route.

Some customers need MCI to buy, truck and ship a car. Others only need one part of that service. I designed four order types so each job shows the stages, fields and actions that actually apply.

01Full service

02Truck + ship

03Ship only

04Truck only

1Buying

2Trucking

3Shipping

4Clearing

5Delivery

The flow changes with the service. Clearing and preparation only appear when they are part of the order.

Bid for Me

I designed the auction bid as an agreement, not a form submission.

A customer or MCI can propose the maximum bid. The other party must accept before the bid goes live. At that point the system reserves 10% of the maximum—with a $1,000 minimum—from the customer’s wallet, so the same funds cannot back another bid.

01Request a carCustomer shares the auction lot or vehicle brief.
02Agree the limitEither side proposes; the other can accept, decline or counter.
03Reserve fundsThe wallet hold activates only after both sides agree.
04Record the resultA lost bid releases the hold. A won bid keeps it reserved.
05Create the orderThe win becomes an order and the deposit is applied to its invoices.

If the wallet is short, the bid waits for funding until the auction starts or 24 hours after acceptance—whichever comes first. The deadline and every hold transition are enforced server-side.

Engineering choices

Keep the frontend deliberately simple

I chose static HTML, CSS and JavaScript over a framework. With two products to build and maintain alone, a zero-build frontend kept deployment fast and each screen easy to trace. Shared modules handled the repeated interface patterns.

Put security in the database

Both products use a public browser client, so hiding an action in the interface was never enough. I used Postgres Row Level Security for access and server-side functions for sensitive writes. The wallet journal cannot be written to directly.

Use two quote engines, not one compromise

US trucking prices come from Central Dispatch market data; ocean shipping uses MCI’s own configurable rate card. I built separate Edge Functions for each, then brought both results into one quote flow for the customer.

Financial integrity

The balance on screen could not be the whole truth.

A customer can reserve funds for an auction bid and still have invoices to pay. I implemented available balance as wallet balance minus active holds, enforced inside the payment functions—not calculated only in the interface. Exchange rates are also saved with each funding event, so a past transaction never changes when today’s rate does.

Wallet

$24,800 available

Balance: $30,000
Active bid hold: − $5,200
Funding rate: ₦1,535 / $1

Outcome

I took the product from workflow mapping to working software.

The work covered product strategy, interface design, data modelling, access control, third-party integrations, transactional email and UAT. The result is one service run through two connected products: enough operational depth for staff, and a much clearer experience for the customer.

2products working together

4service flows mapped

1record for every order

30 secbetween staff alerts