A swipe-first marketplace for buying a used car

A used-car marketplace covering tens of thousands of cars from dealerships across Ireland, with an interface built around swiping instead of searching. Swipe right to shortlist, left to dismiss. From the shortlist you can message the dealership, book a test drive, run a history check on the car, and apply for finance — all without leaving the product.
I worked across the whole thing: the web app, the admin dashboard the team runs it from, and the React Native app on both stores.
The swipe is the interesting decision, and it is a harder engineering problem than a search form.
A filter is a statement of intent: the buyer tells you the make, the budget, the body style. A swipe tells you almost nothing — one bit per card. So the product has to infer what a filter would have been told, from behaviour, fast enough that the second screenful is already better than the first. Get it wrong and the buyer swipes through forty cars, sees nothing they want, and concludes the marketplace has no stock.
The second problem is that a browsing session normally ends where the real work starts. The buyer finds a car, and then leaves to email the dealer, look up the history, and talk to a bank. Every one of those exits is a place the purchase can die somewhere you cannot see.
Full-stack across all three surfaces: the Next.js and React web app, the admin dashboard, the React Native mobile app, and the Node.js backend behind them.
The swipe is not a gimmick borrowed from dating apps — it matches how people actually shop for a car, which is by reaction rather than specification. Most buyers cannot tell you their requirements, but they know instantly whether they like the look of one.
Once you accept that, the design follows: the shortlist is the real product, not the search. And every step after the shortlist has to stay in the app, because a buyer who leaves to email a dealer is a buyer you have handed to whoever replies fastest.
One Node.js backend behind three clients: the Next.js web app, the admin dashboard, and the React Native app. Keeping the shortlist, messaging and booking logic on the server rather than in each client is what let three surfaces behave the same way — the alternative is three implementations of the same rules, drifting apart with every release.
Browsing is a stack of cards rather than a table of results, and the shortlist is treated as the destination rather than a saved search. Messaging, test-drive booking and finance sit on the car itself, so the next step is always in reach of the thing the buyer is looking at.
A marketplace that asks the buyer for a reaction instead of a specification, and then keeps every step after that — the dealer conversation, the history check, the finance — inside the product rather than scattered across four tabs.
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.