Jockey South Africa's Build-a-Pack is one of the brand's most distinctive shopping features - letting customers build their own multi-pack from scratch, choosing every style, size and colour themselves. It's the kind of personalised experience Shopify was never built to support natively, which meant the original version relied on a clever but increasingly fragile workaround. TDMC rebuilt Build-a-Pack from the ground up: consolidating a sprawling, error-prone backend into a single managed system, bringing every product category to true parity, and giving customers more control over their own checkout journey. The result is the same beloved experience Jockey customers know, running on infrastructure built to scale rather than strain.
01
Executive Summary
02
Introduction
Build-a-Pack gives Jockey South Africa customers something most multi-pack offerings don't: real choice. Instead of settling for a pre-set combination of colours they didn't pick, customers choose a category, a style, a size, a quantity, and then hand-select every colour in their pack. It's personalisation at the product level - and it's become one of the most recognisable parts of shopping with Jockey online. The challenge was that Shopify, the platform behind the Jockey South Africa site, isn't designed for build-your-own-bundle functionality out of the box. The original Build-a-Pack was a genuinely clever solution to that gap. But as the feature matured, the workaround holding it together started to show its age.
03
The Problem
Managing the experience meant working across too many moving parts.
Behind the scenes, the original Build-a-Pack relied on 21 separate products and 5 separate colour management areas, with no single place offering a complete view. A pricing change that touched multiple styles meant manually updating each product in turn - a repetitive process with plenty of room for inconsistency.
Even small content updates carried real technical risk.
Adding one new colour could mean uploading six or more images across multiple fields, repeated for every category that colour appeared in. Adding a new style was riskier still - it required uploading a precisely named image file directly into the website's theme files, where a single misplaced character could break the experience entirely.
Not every category was built as an equal.
The No Panty Line Promise range, introduced after the fact, was layered onto the existing flow rather than designed into it from the start. Big Men and Queen weren't standalone categories either - both ran on shared logic borrowed from the Men's and Women's experiences. Over time, this patchwork approach surfaced small but real errors, from incorrect step counters to a style in the Queen category linked to the wrong product entirely.
What had started as a smart solution had, over time, become a system that was difficult to manage, easy to break, and inconsistent in ways customers could occasionally feel.
04
The Solution
One place to manage everything
The new Build-a-Pack replaces 21 separate products with a single product, and consolidates every style's image, sizing, colours and pricing into one editable block. There's nothing scattered to track down - what used to take navigating 5 separate areas now lives in one place, visible and editable together.
Full category parity, built in from the start
Men's, Women's, Big Men and Queen are now four genuinely independent categories, each with its own settings, sizing and styles - no shared logic, no hidden workarounds. The No Panty Line Promise range was rebuilt as a native part of the flow rather than an add-on, with fabric selection and step numbering adjusting automatically depending on the category.
More control for the customer
Where the old flow pushed customers straight to checkout, the new Build-a-Pack adds the finished pack to the cart instead - giving customers the freedom to keep shopping, review their selections, or check out when they're ready.
05
Results
The rebuild didn't change what made Build-a-Pack special - it changed what it took to keep it running.
- Replaced 21 separate products and 5 management areas with a single, centrally managed system.
- Removed the manual file-naming process behind new style additions, eliminating a recurring source of technical risk.
- Brought all four product categories to full, standalone parity for the first time.
- Resolved the small inconsistencies - from step-count errors to mismatched products - that had crept into the original system.
- Gave customers more control over their journey by moving from a forced checkout to an add-to-cart flow.
06
Conclusion
The original Build-a-Pack was never a failure - it was a smart solution to a platform limitation, and it served Jockey South Africa well for years. The rebuild didn't start from a place of fixing something broken; it started from a commitment to understanding exactly how the feature was being used, where it strained, and what Jockey would need from it as the brand kept growing. That's the difference between patching a feature and re-engineering it properly - and it's why Jockey's Build-a-Pack is now built to grow without accumulating the same complexity all over again.
