Online store

Context

An online store lives on two sources of traffic: organic search, which requires indexable and fast product pages, and returning customers, which requires a frictionless purchase journey. Both requirements bear on technical choices made very early.

The problem

Catalogues built in a hurry almost always suffer the same ailments.

• Product pages rendered client-side, and therefore poorly indexed
• Search that slows down as soon as the number of filters grows
• A cart that empties when the customer changes device
• Stock kept in a spreadsheet, out of step with what the customer sees

The solution

A server-rendered site for public pages, faceted search planned into the data model, and a back office that makes the team self-sufficient.

• Category and product pages rendered server-side, for indexing and first paint
• Faceted search: category, size, brand, price, with counts
• Persistent cart, attached to the customer account on sign-in
• A short checkout, with payment handled by an external provider
• Back office for orders, stock and discounts

My role

Site architecture, catalogue and stock model, API, public interface, back office and payment integration. The groundwork went into the catalogue data model, because it determines whether the filters stay fast.

Constraints

• Public pages indexable and fast, including on mobile
• Filters combinable without degrading response time
• Displayed stock has to reflect real stock, including on simultaneous purchases
• Payment data never stored by the application
• Numerous product images, to be served without weighing pages down

Outcome

An indexable catalogue, a search that stays fast as it gets more complex, and a team managing its own products and orders.

• Product pages are served rendered, so search engines can use them
• The cart survives a change of device
• Stock is held in the tool, no longer in a parallel file