Back
A comparison platform that puts electric vehicles side by side on range, price and specs
Project goal
To build a platform where anyone weighing up an electric car can find every model, filter down to the ones that fit and compare them properly on the numbers that decide a purchase.
Our scope
Brand design
UX/UI design
Web development
Project duration
June-November 2024
Technologies used
Laravel
Backpack CMS
Next.js
Redis
Client
EV Data Compare
Buying an electric car means comparing numbers that are hard to pin down
Our client came to us from France with a problem worth solving. Anyone shopping for an electric car runs into the same wall. The specs that actually matter, real range, efficiency, how fast it charges, what it costs on this market, are scattered, inconsistent between sources and quietly different from one model year to the next. EV Data Compare set out to fix that with one place holding accurate data on every model. We built all of it, from the brand through the design to the platform itself.
We started with conversations, not code
Nothing was designed until we understood the thing properly. We opened with a kickoff workshop and worked through what the platform had to do, who it was for, where the data would come from. Only once the concept and the requirements were settled did we move on. It sounds obvious. It is also the step that gets skipped most often. Skipping it is why projects wander, so we did not.
Five rounds of wireframes before a pixel was designed
Then came the wireframes. We did not rush them. The user front went through five iterations. The backoffice went through five of its own. Each round tightened the structure until the flows held up, at which point we wrote the documentation and the development specs, connected the screens into an interactive prototype and handed it to the developers with the thinking already done. Deciding these things on paper is cheap. Deciding them in code is not.
Only then did we choose the technology
With a concept in hand we picked the stack to fit it rather than the other way round. We split the platform into separate services. Laravel with Backpack runs the back end, where the data lives and the editors work. Next.js renders the front, which is what keeps a heavy catalogue feeling light. Redis sits alongside them holding the cached data, because a platform whose whole point is spec tables cannot afford to be slow about showing them.
A brand and a design system built for a data-heavy product
We designed the brand from scratch, then built the design system the platform stands on. A product that is mostly numbers lives or dies on clarity, so the system had to make dense spec tables readable rather than exhausting. Every screen, from the listing through to a single vehicle, comes out of the same set of components.
Filters that cut a full catalogue down to your shortlist
The listing is where most visits start, so filtering had to be quick and deep at the same time. Someone can narrow by the things they care about, price, range, drivetrain, battery, segment and a good deal more, watching the results respond as they go. Results can be read as cards or as a table when someone wants the numbers side by side. Filters follow a visitor around: they survive a switch between metric and imperial, they carry across languages and they come with you when you create an account. Logged-in users can save the ones they use.
A comparison view for the moment before someone spends real money
Comparison is the heart of it. Pick a set of cars and see them laid out against each other, with the differences between them highlighted so nothing has to be squinted at. Anything worth keeping leaves the platform with you: a spec set exports to CSV, or to a PDF report to read away from the screen. It is built for the evening someone sits down and finally decides.
Every generation of a model, so you can see what each facelift actually fixed
This is the part we like most. Electric cars change fast. A facelift can quietly add range or knock a chunk off charging time while the name on the boot stays the same. So a vehicle page does not just show today's version. It opens up the model's earlier generations, other versions of the same car and the rest of the brand's range, which lets someone see exactly what improved between one year and the next. For a used buyer that difference is the whole decision.
Readers who spot a wrong number can say so
A data platform is only as good as its data. The people who notice an error first are usually the readers. So we let them report it. Anyone can flag a specific parameter they believe is wrong, or send general feedback about the platform. The report lands in the backoffice as a discrepancy for the team to check. It turns an audience into a quiet quality-control layer, which is exactly what a catalogue this size needs.
A backoffice built around keeping the data trustworthy
Behind the scenes sits a Backpack CMS shaped around one job: keeping thousands of numbers correct. Editors manage the vehicles, work through reported discrepancies and approve pending changes before anything goes public, with bulk actions for when a batch needs the same treatment. A history log records who changed what and when. Type a metric value and its imperial equivalent fills itself in. The team also runs the blog, the adverts and the platform's configuration from the same place, along with a module for the ten most popular vehicles in each country. An API lets vehicles be added or updated programmatically when they arrive in bulk.
SEO engineered into the build, not bolted on afterwards
A comparison platform lives on search, so we treated SEO as part of the engineering. Structured data goes out on the vehicle and FAQ pages so results show up rich rather than plain. Canonicals, hreflangs and a sitemap keep several languages and countries from tripping over each other. Change a slug and the redirect writes itself. Filtered listings that deserve to be found are indexed while the rest stay out of the way. Even the image alt text is generated automatically as pictures are uploaded, across a catalogue far too large to caption by hand. Core Web Vitals were tuned as a feature, with Cloudflare in front.
Outcome
What we delivered is a full platform: a brand, a design system, a fast public front and a backoffice built to keep the numbers honest. The parts that make it more than a spec dump are the ones we would build again: comparison that highlights what differs, generations that show what each facelift changed and readers who can flag a wrong number and see it fixed.
Let's talk about your project idea!
Tell us about your project. We’ll help you plan the architecture, scope, and execution.
© Webalize 2026
