Most catalogues are organised for the warehouse
This is the single most common defect we find in an e-commerce website, and it is invisible to the business running it. The catalogue is structured the way operations think about stock — by supplier, by part number, by the order the shipment arrived in.
Nobody shops that way. When we started work on LitMeUp, a decorative lighting brand, the catalogue held hundreds of chandeliers and pendants filed under codes like L6627-1H. Customers were asking for photographs over chat, one piece at a time, and the catalogue existed nowhere a search engine could read it.
We kept the part numbers, because operations genuinely run on them, and stopped leading with them. E-commerce development in India often means exactly this kind of translation work: an internal system that is correct for the warehouse, restructured for the person holding a phone.
Two ways in, because customers arrive differently
A serious catalogue needs more than one entry point, and which ones depend entirely on the category.
Some customers know the product. They want a crystal chandelier and they want to compare eleven of them on finish and price. Others know only the problem — they have a dining table and nothing above it. Those two people need different navigation, and forcing both down a single category tree loses one of them.
For LitMeUp that meant browsing by style and browsing by room, plus a visualiser for placement. For a parts business it means part-number search sitting alongside browsing by machine. The pattern generalises; the specific answer never does, which is why this is decided in discovery rather than assumed.
The product page is where the sale is won or lost
Everything a customer needs in order to stop hesitating belongs on the product page, next to the price — not on a policies page they will never open.
Size and finish options that reflect real stock. Delivery expectation. Warranty. Returns. For considered purchases, the thing that closes the sale is usually the answer to a fear, and the fear is specific to the category: will it fit, will it arrive intact, what happens if it fails in year two.
We instrument these pages properly too, because the drop-off point tells you which fear you have not answered yet.
Fast, on a dense image grid, on mobile data
E-commerce is the hardest performance problem in web development. A category page is a wall of photographs, every one of which matters to the sale, loading over a connection worse than the one you tested on.
So the storefront is built static-first: pages pre-rendered rather than assembled on request, images served in modern formats at the size they actually render, and the product grid built so it does not shift as photography arrives. That work is also SEO work — a category page that renders fast and carries readable structure is a page search engines can rank, which a chat-based catalogue never was.
What you run yourself
New arrivals should not require a developer. Anything meant to change regularly — products, pricing, imagery, collections, seasonal merchandising — is editable without touching code, and handover includes a walkthrough recorded against your own store.
Payments, delivery configuration, analytics and conversion tracking are set up and verified at launch rather than promised for later. And the accounts are yours: domain, hosting, payment gateway, repository.