Shoppers on a fashion marketplace rarely arrive knowing the product they want. They arrive with a sense of an occasion, a silhouette, a way of dressing. The client had a catalogue that could only answer precise queries, so browsing customers left without a search term they knew how to type. ELIVTECH rebuilt discovery around user-curated collections, backed by a Laravel commerce core and an Elasticsearch layer that ranks a feed as readily as it ranks a search result.
The marketplace aggregates independent fashion sellers across a wide size and price range. Its original storefront treated discovery as a search problem, which suited the small share of visits that began with intent and failed the majority that began with inspiration. Returning customers had no way to find the item they had bought before, and sellers had no signal about which products belonged together. ELIVTECH rebuilt the platform on Laravel with a React storefront, introduced collections that customers assemble and follow, and moved ranking into Elasticsearch so the same relevance model serves search results, category listings and a personalised feed. Size and fit became first-class filters rather than product-description text.
At a glance
The challenge
A catalogue built to answer questions, serving customers who had not formed one yet.
Discovery that required a query
The storefront opened on a category grid and a search box. Customers browsing for an occasion rather than a product had no entry point, and the paths that did exist ranked by recency, so the same recent uploads dominated regardless of who was looking or what they had shown interest in before.
Size and fit buried in prose
Sellers described measurements in free text, in different units and conventions. Filtering by size was unreliable, so customers ordered across sizes to find one that fit and returned the rest. The cost of that behaviour fell on sellers and on the returns operation rather than on the catalogue that caused it.
No path back to a previous purchase
Repeat buyers could not find an item they had bought before once the seller's listing rotated or the variant changed identity. Reordering meant searching from scratch and hoping the same product surfaced, which turned the most reliable kind of demand into a manual hunt.
Curation with nowhere to live
Customers and stylists grouped products informally in wishlists and shared screenshots, but the platform had no object to hold a collection, no way to follow one, and no way to feed that signal back into ranking. The most useful merchandising input the marketplace generated was being discarded.
An interface that fought browsing
Long pages of uniform tiles, filters hidden behind a modal, and a layout that reflowed as images loaded. Browsing is a scrolling activity and the storefront made scrolling expensive, particularly on the mobile connections where most of the session time was spent.
Relevance logic scattered across the codebase
Category ordering, search ranking and promotional placement were each implemented separately in application code. Changing how products were prioritised meant editing three places and deploying, so merchandising decisions moved at the pace of the release calendar.
Our solution
One relevance layer serving search, category and feed, with collections as the object that carries taste.
Discovery Research and Catalogue Modelling
Four weeks of session analysis and customer interviews established how people actually navigate a fashion marketplace, followed by a catalogue remodelling exercise that turned free-text measurements into a structured size and fit schema. Sellers were given a guided listing flow that captures garment measurements per size, so fit data enters the system as data rather than as description. Existing listings were migrated by a review queue that proposed structured values for a seller to confirm, which avoided silently guessing measurements on stock already for sale.
Laravel Commerce Core and React Storefront
The commerce domain was rebuilt on Laravel with clear boundaries around catalogue, collections, orders and seller settlement. The storefront is a React application consuming a versioned API, built for continuous scroll with virtualised lists, reserved image space to keep layout stable, and filters that remain visible while results update beneath them.
Collections and the Personalised Feed
Collections became a first-class entity that customers and stylists create, follow and share. Follow relationships, saves and reorders feed a ranking signal stored alongside the catalogue, and the home feed is assembled from followed collections, affinity to previously purchased attributes and editorial placement, with the mix controlled from the admin rather than in code.
Elasticsearch Relevance and One-Tap Reorder
All ranking moved to Elasticsearch. Search, category listing and feed assembly resolve through the same index with different boosting profiles, so merchandising rules apply consistently. Purchased items are pinned to a stable product identity that survives seller relisting, which makes reorder a single action even when the underlying listing has been recreated. Where the original seller no longer stocks an item, the same identity resolves to equivalent listings from other sellers, so a repeat purchase degrades into a close match rather than a dead end.
Technology stack
Results
Measured once the React storefront and the shared relevance layer were serving all traffic.
Before and after: platform engineering measures
- Discovery required a search term the customer had to supply
- Size and fit held as seller free text in mixed conventions
- No way to return to a previously purchased item
- Curation happened off-platform in screenshots and wishlists
- Ranking logic duplicated across search, category and promotions
- Layout reflowed as images loaded during scroll
- Merchandising changes waited for the release calendar
- Home feed assembled from followed collections and purchase affinity
- Structured garment measurements captured per size at listing time
- Reorder in one action against a stable product identity
- Collections are first-class objects that can be followed and shared
- One Elasticsearch relevance layer with per-surface boosting profiles
- Virtualised lists and reserved image space keep scroll stable
- Merchandising boosts and synonyms configured from the admin
Project timeline
Discovery Research and Catalogue Modelling
Session analysis, customer and stylist interviews, size and fit schema design across garment categories, seller listing flow prototyping, and the target Laravel and Elasticsearch architecture.
Commerce Core and API
Laravel domain build across catalogue, collections, orders and seller settlement, MySQL schema with stable product identity, queue-backed background processing, versioned storefront API, and the deployment pipeline on containerised AWS infrastructure.
React Storefront and Fit Experience
Virtualised browse and search surfaces, persistent filter panel, reserved media space to hold layout stable, guided seller listing capture, and size recommendation driven by structured garment measurements rather than seller description.
Collections and Relevance Layer
Collection creation, following and sharing, affinity signal capture from saves and reorders, Elasticsearch index design with per-surface boosting profiles, alias-based reindexing, and admin controls for synonyms and placement.
Hardening and Progressive Rollout
Core Web Vitals tuning on browse surfaces, accessibility remediation on filters and the listing flow, load testing on feed assembly, CloudWatch dashboards on ranking latency, then a progressive rollout with the previous storefront available as fallback.
Key takeaways
What shaped the engineering decisions
- One relevance layer, many surfaces: Keeping separate ranking code for search, category and promotions was rejected because the three drifted apart and merchandising had to be re-implemented for each. A single Elasticsearch index with per-surface boosting profiles made ranking a configuration concern.
- Capture fit as data at listing time: Parsing measurements out of seller prose after the fact was rejected as unreliable across units and conventions. A guided listing flow that captures measurements per size costs the seller a little more effort once and makes filtering trustworthy for everyone afterwards.
- Give products an identity sellers cannot break: Reorder depends on a product surviving relisting. A stable identity separate from the seller's listing record means a repeat purchase resolves even when the original listing has been recreated under a new title.
- Model curation as an object, not a feature: Collections that can be created, followed and shared turn customer taste into a signal the ranking layer can consume, rather than activity that ends in a screenshot outside the platform.
- Browsing is a rendering problem: Virtualised lists and reserved image space were treated as core requirements rather than polish, because layout shift during scroll is the failure mode that ends a browsing session on a mobile connection.
- Reindex behind an alias: Rebuilding the index in place degrades results while it runs. Writing to a fresh index and swapping the alias made schema changes to the fit and affinity fields a routine operation with an immediate rollback path.
Want results like these?
Let's discuss how ELIVTECH can drive measurable outcomes for your business.
Start your project