I built CarVendors, a UK used-car marketplace, across frontend, backend, and DevOps responsibilities. The project involved vendor workflows, listing management, search/filtering, review features, GDPR/cookie consent, data pipeline work, and deployment automation. This post breaks down the architecture, key decisions, and lessons from shipping a real marketplace — a practical case study rather than a tidy theory piece.
Project context
CarVendors is a marketplace where used-car vendors list stock and buyers browse, filter, and review. I worked solo on it across frontend, backend, data workflows, and deployment, and the site is live.
Working alone on every layer changes how you make decisions. There was no separate backend team to hand an API contract to, and no DevOps engineer to own the pipeline. That sounds harder, and in some ways it is, but it also removes a lot of coordination overhead. When the search endpoint needed a new filter, I changed the query, the API, and the UI in one sitting. The trade-off is discipline: with no second pair of eyes, I leaned on typed boundaries and consistent conventions to catch the mistakes a reviewer normally would.
CarVendors runs on a PHP and MySQL stack with JavaScript on the front end and GitHub Actions for deploys — a pragmatic choice for the hosting and timeline it needed. The lessons in this post are about marketplace architecture and data design, not a specific framework, so they carry straight over to the Next.js, React, and Laravel stack I reach for on most projects today. Wherever the framework mattered, I focus on the principle: listing pages must render fast and stay crawlable, and the boundary between the UI and the data layer should be strict enough that a bad field fails loudly rather than silently in production.
Why marketplace architecture differs from a normal website
A brochure site has one audience and mostly static content. A marketplace has at least two audiences with opposing needs, and the content is created by the users themselves.
Buyers want fast, trustworthy browsing: accurate listings, sensible filters, and reviews they can believe. Vendors want control: a place to add and edit stock, manage their own listings, and not step on anyone else's data. Those two jobs pull the architecture in different directions. The public side is read-heavy and benefits from rendering and caching. The vendor side is write-heavy, gated behind authentication, and full of validation rules.
The second difference is data ownership. On a normal site, you write the content. On a marketplace, vendors and an import pipeline write most of it, which means you cannot assume anything is clean. Every listing needs validation on the way in, and the public pages have to degrade gracefully when a field is missing. I designed the data model around that reality from the start: a relational shape where vehicles, vendors, listings, and reviews each have clear ownership, and where a listing always knows which vendor it belongs to.
Vendor dashboard, listing logic, and search
The vendor experience is the heart of the system, so I'll group it with the buyer-facing search, because the two share the same data and have to agree.
Onboarding brings a vendor into the system and gives them a dashboard. From there they manage their own listings — creating, editing, and removing stock — without ever touching another vendor's records. Enforcing that ownership boundary was a recurring theme: every write checks that the logged-in vendor owns the record being changed, and the queries that power a vendor's dashboard are scoped to that vendor only. Get this wrong on a marketplace and you have a serious data-leak problem, so it gets tested deliberately rather than assumed.
Listing management also means validation. A car listing has structured fields — make, model, year, price, mileage, and so on — and each needs rules so the public search stays meaningful. If mileage can be free text, your "under 50,000 miles" filter quietly breaks. So validation on the write side and the filter logic on the read side are really the same design decision viewed from two ends.
That feeds directly into search. Buyers filter across multiple fields at once — make, model, price range, and others — and combine them. The work here is turning a set of optional filters into one efficient query without a tangle of conditionals, and keeping the result fast enough to feel instant as someone narrows things down. Because the public listing pages are server-rendered, a filtered search produces a real URL that search engines and shared links can both use, which matters for a marketplace that wants organic traffic.
GDPR and cookie handling
CarVendors serves UK users, so consent was not optional and not something to bolt on at the end. I handled cookie consent up front: visitors get a clear choice, non-essential cookies do not fire until they opt in, and that preference is respected on later visits.
The honest lesson here is that consent touches more of the codebase than you expect. Anything that sets a cookie or loads a third-party script has to sit behind the consent gate, which means the consent state has to be readable from many places. Treating it as a first-class part of the app — a known state the rest of the code can check — was far cleaner than scattering conditional script tags around. For a UK marketplace handling vendor and buyer data, getting this right is part of being trustworthy, not just a legal checkbox.
Data pipeline and scraper work
A car marketplace is only useful if it has cars in it, and expecting every vendor to hand-type their whole inventory is unrealistic. So part of the build was a data import and scraper pipeline that pulls vehicle listings into the system.
The interesting problems here are not the fetching — they're everything after. Source data is messy: fields are named differently, values arrive in formats your schema does not expect, and duplicates are common. The pipeline's real job is normalisation: mapping incoming data onto the same structured fields the manual listing form uses, so a scraped car and a hand-entered car are indistinguishable downstream. That shared target is what keeps search and filtering reliable regardless of where a listing came from. I also had to make the pipeline tolerant of bad rows — skip and log what it cannot parse rather than letting one malformed record stop the whole import.
Deployment, handover, and what I would improve next
On the DevOps side I set up deployment automation so shipping a change was a repeatable, low-drama step rather than a manual chore. Automating deploys early pays for itself because you can ship small changes often without being afraid to deploy. Part of solo work is also leaving the project in a state someone else can pick up, so consistent conventions and a predictable structure were as much about handover as about my own sanity.
If I were extending CarVendors now, a few things are on my list. I would push harder on automated test coverage around the vendor-ownership boundaries and the search-filter logic, since those are the two areas where a silent bug does the most damage. I would invest more in observability around the import pipeline, so a change in a source format surfaces as an alert rather than as quietly missing listings. And I would keep tightening the listing schema, because every constraint you add on the write side removes a class of bug on the read side.
FAQ
Did you build CarVendors solo?
Yes. I handled frontend, backend, data workflows, and deployment myself. The site is live.
What was the hardest part?
Data integrity. Between vendor-submitted listings and a scraper pipeline, most of the content was created by other people or systems, so validation and normalisation mattered far more than any single feature.
What would you build a marketplace on today?
Next.js with React and Laravel. Server-rendered listing and search pages stay indexable and shareable, and a typed boundary between the UI and the data layer catches mistakes early — which matters most when you are the only reviewer. CarVendors proved the architecture on a PHP/MySQL stack; the framework I reach for now just removes more of the glue.
Next step
If you are planning something similar, I take on a small number of build-and-ship projects and can help end to end. Have a look at my marketplace development service for how I approach vendor workflows, search, consent, and deployment — or get in touch with your scope and I'll come back with indicative pricing after a proper look.
Related: CarVendors project breakdown