Stickers & Banners

A browser file upload is a single HTTP request. For a 1GB print file on an ordinary connection that request runs for many minutes, and the probability that nothing interrupts it over that window is not high. When it fails, it fails completely — no partial credit, no resume, and the customer starts again from zero having already waited.

Routing that through the application server is also the wrong shape: it means paying for the bytes twice and holding a long-lived request open for the duration.

The file is segmented client-side and each segment is sent directly to object storage against a short-lived pre-signed URL, so the bytes never touch the application server. Each segment succeeds or fails independently, which means a failure costs one segment rather than the whole file, and retries are automatic and invisible.

Server-side processing — validation, dimension and resolution checks, preview generation — runs on upload completion rather than inline, so the customer is not waiting on it and the work scales with orders instead of with request handlers.

Custom print is configurator-heavy in a way standard commerce is not — dimensions are continuous rather than variant-based, and price is a function of size, material and finish rather than a lookup. Pricing is computed live as the customer adjusts, and the resulting line items are assembled through a Shopify cart transform so the cart reflects the true configured product rather than a placeholder.

Progress reporting should have been built before retry logic, not after. For the first iteration the retries worked correctly and silently, which meant a customer on a bad connection saw a progress bar that appeared to stall — and reloaded the page, discarding work that was actually succeeding. Correct behaviour that the user cannot observe reads as broken behaviour.