E-commerce / interactive
Custom device cover configurator
A dependency-free configurator that lets customers design a cover for their exact device and add it to the cart — engineered in vanilla JavaScript to stay smooth on old, low-powered phones.
Overview
Customers wanted to design their own cover — for their exact phone, tablet or laptop — with their own images and layout, and then buy it without ever leaving the shop they were already in. The catch was performance: this had to run smoothly on the kind of older, low-powered phone that a lot of customers actually use, not just on a developer’s flagship device.
Problem
Interactive configurators are usually where front-end weight goes to die. Reach for a heavy framework and a rich canvas library and the experience is lovely on a new device and a slideshow on a three-year-old one — which is exactly the device many buyers are holding. The performance budget wasn’t a nice-to-have; it was the whole brief. And it all had to slot into an existing storefront and checkout, not replace them.
Solution
I built the configurator in vanilla JavaScript — no framework overhead to drag down older hardware. Customers pick their exact model, design a custom cover with their own images and layout, and add the finished product straight to the cart through the existing e-commerce system. A Laravel API backs it with device data, image handling, and order integration.
The result is a fast, dependency-free configurator that stays smooth even on older phones and is fully integrated with the storefront and checkout that were already there.
Architecture
The split is clean: a lightweight client that owns all the interactivity, and a Laravel API that owns everything the client shouldn’t be trusted with — the device catalogue, image processing, and turning a design into a real order in the existing shop.
On the client, going vanilla was a deliberate architectural decision, not nostalgia. Direct control over the DOM and rendering meant direct control over the performance profile: no reconciliation cost I didn’t ask for, no bundle I didn’t need. The image handling — uploading, positioning and previewing a customer’s own artwork on the right device shape — was the part that most needed to be fast and cheap on the client, and offloaded to the API where it was heavy.
Technical challenges
Making a rich, image-heavy interaction feel instant on constrained hardware is a discipline of subtraction. Every feature had to justify its cost in milliseconds and memory: how images are loaded and scaled, how the preview updates as the customer drags, how much work happens per frame. And it all had to happen inside someone else’s storefront — respecting the existing cart and checkout contracts rather than working around them, so the custom product behaved like any other line item.
Lessons learned
The right tool is the one that fits the constraint, and here the constraint was other people’s old phones. Choosing vanilla JavaScript over a framework wasn’t a statement about frameworks — it was the smallest thing that met the performance bar and integrated cleanly. It’s a good reminder that “modern stack” and “right stack” aren’t synonyms, and that the most impressive engineering is often the stuff you chose not to include.