A price comparison app where a wrong match costs the client money

The client wanted to build a business on affiliate marketing: a shopper searches for a product, sees what every outlet charges for it, and taps through to buy — with the client earning a commission on that tap.

That model makes one thing non-negotiable. The price has to be right. Show a shopper a deal that turns out to be a different product, and they do not buy, they do not come back, and the commission never happens. A comparison app that is confidently wrong is worse than no app at all.

And retailers do not agree on what anything is called. The same tub of whey protein is titled six different ways across six sites, padded with marketing words, flavour names, pack sizes and free gifts. An early version matched listings using a list of words that signal a bundle — combo, bundle, + — and it failed the moment a retailer invented new phrasing. "Duo". "Twin Pack". "Free Gift". When it missed, a "Whey + Creatine" bundle was merged into the plain whey product, and the page showed a price two or three times the real one, sitting beside the correct prices and looking just as trustworthy.

A mobile app in React Native and Expo, on a Bun and Elysia backend with Postgres and Meilisearch underneath. The app and the API share their types through Elysia Eden, so a change to the backend breaks the app's build rather than failing in a shopper's hands.

The matching engine was rebuilt around structure instead of phrasing. Rather than listing the words that indicate a bundle, it extracts the product nouns a title contains, against a taxonomy for each category. A title naming both whey and creatine is structurally a bundle however it is worded, and it cannot merge with anything that is only whey. Pack counts are pulled out as a number and compared strictly, so a pack of two can never be averaged into a pack of one.

That rule fails closed, on purpose. When one retailer titles a product carefully and another lazily, the engine sometimes misses a merge and the same product appears twice. We chose that over the alternative. Two listings for one product is untidy; one listing for two products is a wrong price, and a wrong price is the one thing this client's business cannot survive.

Sources are routed by category rather than all queried at once. The general marketplaces see every search, beauty and fashion outlets only see beauty and fashion, and a nutrition brand only ever sees nutrition — which keeps searches fast and avoids asking a retailer about products it has never stocked. Amazon is reached through its official API, under a strict rate limit.

Because the catalogue is the client's core asset, destructive deletes on live product data are ruled out entirely: anything suspicious is flagged for review and can be restored instantly. And product resolution runs under a database lock, so two searches for the same new product at the same moment cannot create it twice.

The app is in active development with the client, so there are no launch figures to report yet — and we will not put invented ones here.

What works today: search and comparison end to end across Amazon, Flipkart, Myntra, Ajio, Nykaa, Croma and the HealthKart brands, the structural matching engine described above, and an admin dashboard that records not only which sources answered a search but why an empty one came back empty — so the client can see a problem instead of guessing at one.

The lesson we have carried into every project since: the expensive failures are not the ones that crash. They are the ones that return a plausible answer. Most of what we built here exists to make this system fail loudly rather than quietly.