PIDY — Shopify app & try-on

PiDY is a fashion-technology product: it takes photographs a shopper has taken of themselves, extracts body measurements from them, and generates a personalised fit visualisation so people can see how a garment will actually sit before they buy it. It reaches shoppers two ways — through a widget inside a brand's own online store, and directly.

This is a team product built by a company, and the honest description of the involvement matters more than the size of the claim. The work here was on two parts of it: the Shopify application, as its largest contributor, and the try-on experience, as its largest human contributor. The backend schema was a smaller contribution alongside other engineers, and the mobile application was somebody else's work entirely.

The Shopify application had one constraint that determined its whole architecture: the code injected into a merchant's storefront had to stay under five kilobytes. Not five kilobytes of framework — five kilobytes total. So the piece that lives in the shop is plain JavaScript and CSS, a button and a result area, with no framework, no library and no external fonts. Everything heavy — signing in, the body scan, the try-on itself — runs in a popup on PiDY's own domain. Nothing is requested and nothing is loaded until a shopper actually clicks. The reasoning is worth stating: every layer of abstraction is a failure point, and this one would be replicated across thousands of merchant stores that nobody can debug individually.

It also holds a strict boundary. The Shopify application never reads the product's own domain data — no products, no scans, no try-on sessions. It owns four tables of its own concerning Shopify and nothing else: sessions, a webhook log used to make repeated deliveries safe, a billing cache and an audit trail. Everything else goes through the core API. Shopper photographs and generated imagery are served only through signed, expiring links; there are no permanent public URLs for them.

On the try-on side the work concentrated on the path from signing in to seeing your first avatar — authentication, onboarding, the processing screen and the reveal. Avatar generation is slow and expensive because it runs on GPUs, so it was built as an asynchronous job with a primary provider and a fallback, rather than a request somebody waits on.

One bug from that work is worth keeping because it is so easy to get wrong. The sign-in popup was being blocked by browsers, apparently at random. The cause was that a popup must be opened synchronously inside the click handler — put a single await before it and the browser treats it as unrequested and kills it. The fix was to keep the values needed in synchronous references, populated in advance by the auth state listener.