Replacing a $75k third-party image viewer with native platform capabilities

The existing PDP gallery delegated its entire DOM, image transformations, 360-degree sets, video injection, and responsive behavior to a third-party viewer SDK. The package behaved as a black box, so even routine storefront changes had already required monkey-patching and configuration overrides.

Beyond the maintenance cost, the integration carried approximately $75,000 in annual licensing cost. The engineering question was whether native Salesforce B2C Commerce capabilities could replace it without sacrificing the customer experience.

I decomposed the viewer into explicit capabilities: multiple thumbnails, synchronized large images, animated GIFs, video slides, 360-degree spin frames, and responsive image transformation. Each capability was evaluated against SFRA product models, Business Manager image view types, WebDAV storage, and Salesforce Dynamic Imaging Service.

The implementation scope was SFRA, but the media data could not depend on a specific DOM structure. The same arrays and media metadata needed to remain consumable by a future PWA implementation. Existing assets would be managed in Salesforce; bulk image migration was intentionally separated from the architecture spike.

Standard product images come from the SFCC product image model and configured view types. A responsive-image utility builds breakpoint-based srcset values using Dynamic Imaging width parameters and automatic format negotiation. Animated GIFs deliberately bypass transformations so animation is preserved.

The storefront gallery uses the Slick library already present in the codebase, pairing synchronized main and thumbnail sliders without adding a dependency. Video becomes a first-class media slide configured through product attributes and loaded only when requested.

For 360-degree views, the server produces an ordered frame array from product attributes or a dedicated Business Manager image view type. A small client module uses native pointer events to implement drag-to-spin and lazy-loads frame URLs. The resulting array can be consumed by SFRA today or by PWA components later.

The old and new galleries were designed to coexist behind an existing product-level flag. That allowed content migration and feature validation to happen incrementally instead of coupling a cartridge removal, asset migration, and storefront release into one high-risk change.

Only after the native path reached parity would the external cartridge, site preferences, and obsolete product attributes be removed. This preserved rollback options and separated technical rollout from content-team timing.

The investigation surfaced the details that typically disappear in a simple carousel rewrite: animated formats cannot pass through automatic conversion, spin frames need ordering conventions, video metadata needs content-team ownership, and image view types impose practical limits.

Dynamic Imaging covered responsive resizing and modern format negotiation. Focal-point cropping remained the one capability requiring additional validation and, where needed, explicit crop parameters. Styling was deliberately left outside the proof of concept because the native template gives the product team full control once the architecture is accepted.

The proof of concept demonstrated a path away from a costly, brittle black box toward code the team can inspect, test, style, and evolve. It reused platform features and an existing library, introduced no new frontend dependency, preserved the future PWA path, and made media behavior explicit in the product model.