A national eyewear retailer was selling a prescription product through a storefront that could only sell a frame. Customers picked glasses online, then finished the medical half of the purchase over email or in a store. ELIVTECH rebuilt the business on Shopware, modelling the prescription as part of the cart itself, and rebuilt discovery on Elasticsearch so that frames could be found the way people actually choose them.
The retailer ran six regional storefronts on separate codebases, each with its own catalogue import, its own theme and its own release calendar. Prescription details were collected after checkout, which meant every online order carried an open question until someone resolved it by phone. ELIVTECH consolidated the six storefronts onto a single Shopware platform with a shared catalogue and per-region sales channels, extended the cart to carry lens prescriptions as first-class line-item data, and moved product discovery to Elasticsearch with fit and face-shape faceting. The platform runs on AWS behind an infrastructure-as-code pipeline, and the store network now sells from the same stock ledger as the website.
At a glance
The challenge
A storefront built for accessories was being asked to sell a regulated optical product across six regions.
Prescriptions collected after the sale
The cart could take a frame and a lens type, but nothing else. Sphere, cylinder, axis, addition and pupillary distance were gathered afterwards by email or phone. Orders sat in a holding state until a person chased the customer, and lab dispatch waited on that exchange rather than on the payment.
Discovery that ignored how people choose frames
Filtering was limited to brand, colour and price. Shoppers reason in terms of face width, bridge fit, temple length and whether a frame accepts progressive or high-index lenses. None of that was queryable, so customers browsed long unfiltered grids and abandoned the journey before reaching a product page.
Six storefronts, six codebases
Each region maintained its own deployment, catalogue importer and theme. A pricing rule or a compliance change had to be written and tested six times. Regional teams drifted apart in behaviour, and no one could state with confidence what a given product looked like across every market.
Stock the stores and the site disagreed about
Store inventory reached the website through an overnight file. Customers reserved frames the branch had already sold that morning, and staff resolved the conflict at the counter. Click-and-collect could not be offered responsibly while availability was a day behind reality.
Accessibility gaps in a vision-care journey
Low-contrast filter controls, unlabelled form inputs and keyboard traps in the lens configurator sat in a purchase path used specifically by people with impaired sight. The gap was both an inclusion failure and a compliance exposure the business had no measurement for.
Releases that required downtime
Deployments involved manual file synchronisation and a maintenance window, so changes were batched into a release roughly every three weeks and shipped outside trading hours. Catalogue reindexing locked search for hours, which pushed imports into the same fragile window.
Our solution
One Shopware platform, a cart that understands optical data, and search rebuilt around how frames are actually chosen.
Discovery and Domain Modelling
Three weeks mapping the optical domain before writing platform code: prescription validity rules, lens compatibility by frame material and rim type, regional dispensing requirements, and the six regional catalogues reconciled into one master product set. The output was a shared taxonomy and a written contract for how a prescription travels from cart to lab, which every later decision was tested against.
Shopware Core and Prescription Cart Extension
Shopware was configured with one product catalogue and six sales channels, each carrying its own pricing, tax rule and content. The cart was extended so a prescription is validated and stored as structured payload on the line item, using Shopware's cart collector and processor chain. Validation runs server-side during price recalculation, so an incompatible lens and frame pairing cannot survive to checkout.
Elasticsearch Catalogue and Fit-Based Merchandising
Product discovery moved to Elasticsearch with documents denormalised per sales channel and language. Frames carry measured fit attributes, face-shape affinity and lens-compatibility flags as filterable fields, with variant stock nested inside the parent document. Merchandisers control boosting and synonym sets from the admin, so seasonal ranging no longer requires a developer or a deployment.
Store Fulfilment, Accessibility and AWS Delivery
A custom stock provider reads branch inventory in near real time, enabling reserve-and-collect against the same ledger the counter uses. The storefront was rebuilt to WCAG 2.2 AA on core journeys and tuned against Core Web Vitals. Infrastructure is defined in Terraform and deployed to containers on AWS through a pipeline with automated checks and a one-step rollback.
Technology stack
Results
Measured against the pre-migration baseline once all six regions were serving from the new platform.
Before and after: platform engineering measures
- Prescription collected by email after the order was placed
- Filtering limited to brand, colour and price
- Six regional codebases, six separate release calendars
- Branch stock published to the site on an overnight file
- Reindexing locked search and ran in a maintenance window
- No accessibility baseline on the lens configurator
- Deployments required downtime outside trading hours
- Prescription validated in the cart and carried to the lab with the order
- Faceting on fit measurements, face shape and lens compatibility
- One codebase, six sales channels, one deployment
- Branch stock read in near real time for reserve-and-collect
- Alias-swap reindexing runs during trading hours
- WCAG 2.2 AA verified on core journeys, checked in the pipeline
- Releases ship during business hours with one-step rollback
Project timeline
Discovery and Architecture
Optical domain modelling, reconciliation of six regional catalogues into one master product set, audit of lab and store integrations, Core Web Vitals and accessibility baselining, and the target Shopware sales-channel design.
Platform Foundation
Shopware installation on containerised AWS infrastructure defined in Terraform, MySQL schema and catalogue import build, sales-channel configuration per region, Redis session and cache layer, and the CI/CD pipeline with automated test gates.
Prescription and Fitting Experience
Cart extension for structured prescription payloads, server-side validation in the price recalculation chain, lens and frame compatibility rules, encrypted storage of optical data, and the guided lens configurator built to keyboard and screen-reader standards.
Search, Merchandising and Store Fulfilment
Elasticsearch index design and mapping, denormalised per-channel documents with nested variants, alias-based reindexing, admin-controlled synonyms and boosting, and the near real-time branch stock provider behind reserve-and-collect.
Hardening, Accessibility and Regional Cutover
Load testing against campaign traffic profiles, WCAG 2.2 AA audit and remediation, Core Web Vitals tuning, CloudWatch dashboards and structured logging, then region-by-region cutover with the legacy storefronts held in reserve until each market was stable.
Key takeaways
What shaped the engineering decisions
- Model the prescription, do not multiply the product: Representing every prescription combination as a Shopware variant was rejected early. The permutations are effectively unbounded, and each one would carry stock and pricing records that mean nothing. Structured line-item payload keeps the catalogue finite and the optical data intact.
- Keep validation on the server, in the price chain: Client-side checks alone would have let an unsupported lens and frame pairing reach the lab. Running validation inside the cart processor means the rule is enforced on every recalculation, including API and in-store kiosk orders.
- Index for the question, not the schema: Elasticsearch documents were denormalised per sales channel and language with variant stock nested inside the parent, so a fit-and-availability filter resolves in one query rather than a fan-out the database would have had to absorb.
- Reindex behind an alias: Rebuilding in place was rejected because it degrades results while it runs. Writing to a fresh index and swapping the alias atomically made reindexing a routine daytime operation and gave an instant rollback path if a mapping change misbehaved.
- Treat optical data as sensitive from the first commit: Prescription records are encrypted with managed keys, access is scoped to the roles that dispense, and retention is enforced by policy rather than convention. Retrofitting that after launch would have meant reworking the cart.
- Accessibility is a supply-chain of small decisions: Contrast tokens, labelled inputs and a keyboard-navigable configurator were built in and then checked automatically in the pipeline, so the standard holds as the storefront changes instead of decaying between audits.
Want results like these?
Let's discuss how ELIVTECH can drive measurable outcomes for your business.
Start your project