An electric-vehicle marketplace and advice platform for a national market
A national marketplace for electric vehicles, aimed at the moment before the purchase rather than the purchase itself. You can browse new and pre-owned EVs, filter by type and body style, compare models side by side, plan a route with charging stops included, reach finance, and read the reviews and explainers that make any of it meaningful.
I worked across the front end and the admin dashboard behind it.
The obvious version of this product is a listings site with a filter. That version does not work, because the person using it has not decided anything yet.
Somebody considering their first electric car is not comparing trim levels. They are stuck on three questions — will it get me to where I actually drive, what does it really cost to run, and can I afford it this month — and none of those is answered by a grid of vehicles. A marketplace that only lists cars sends that person away to find the answers elsewhere, and they buy wherever they found them.
So the engineering problem is a content and data problem wearing a marketplace's clothes: several different kinds of thing — vehicles, chargers, routes, finance products, editorial — have to sit in one interface without it turning into a directory.
Full-stack: the Next.js and React front end, and the admin dashboard the team uses to manage listings and content. Django on the backend.
The decision that shapes everything: treat the buyer as undecided. Once you do, features that look like extras become the core — the journey planner is not a gimmick, it is the direct answer to the single most common reason people do not buy an electric car. Comparison is not a spec table, it is the tool that turns a shortlist into a choice.
And the editorial is not marketing. It is what makes the person trust the marketplace enough to use its finance.
Next.js and React on the front, Django behind. The mix of content types is the part that shapes the architecture: vehicle listings change often and are queried hard, editorial changes rarely and is read constantly, and charging and route data comes from elsewhere entirely. Treating those as one thing produces either a slow site or a cache that lies, so they are fetched and cached according to how each actually behaves.
The interface is built so that a visitor who does not yet know what they want can still make progress — comparison and the journey planner are reachable from the browse experience rather than hidden behind a decision the visitor has not made.
A marketplace built for the part of the purchase that actually blocks people — the decision — with the listings, the comparison, the route planning and the finance in one product rather than scattered across four.
If this sounds familiar
Building something similar?
Most of these problems show up again in different clothes. Describe yours and I will tell you what I would look at first.