Creating Bundles & Product Builders with Shopify & Shopify Plus - The Definitive Guide

One feature within ecommerce that has always been pretty common, but which has been becoming an even bigger trend with more complex implementations is the topic of bundling. In recent years, discussions around bundling often evolve to also incorporate the idea of builders. 

Shopify has many positives, but it does have weak areas and one of those is the native ability for bundling. This can be a huge source of frustration when trying to achieve objectives in the desired way, especially so when other platforms, such as Magento or BigCommerce, have really considered and flexible offerings straight out of the box. We have done a lot of work on a re-platforming project with a client recently who began the requirements gathering process as big fans of Shopify. But with bundling & product customisation such a major part of their business model, the amount of development effort and unknown to get the desired results on Shopify didn’t make sense - and so it was ruled out as a suitable platform for that project.

Before digging into the specifics of what is achievable on Shopify and how, this is an overview of what the definitions of Bundles & Builders are through this guide:

Bundles

Grouping a fixed set of existing products, multiple SKUs but often sold together as one single product or order line, usually at a set discounted cost.

Example:

https://www.boroughkitchen.com

Builders     

Offering customer interaction to select and configure from a range of products or options, sold together as one SKU. This is perceived as (or genuinely is) unique to that customer. Pricing or Discounts are calculated based on the selections made by that customer.

Examples: 

https://niococktails.co.uk

https://fentonand.co/collections

Arguably the most important factor to consider before getting to the frontend experience, is how the bundle/builder orders coming into Shopify need to be structured - particularly to reflect changing inventory levels. This is critical at a larger scale, for example when connected to an ERP or if there is a complex setup with a multistore approach that shares inventory sources. Some important backend considerations are:

• Does each bundle have a ringfenced inventory of its component products (The products within it), so that it becomes a standard product in itself with a stock level? If these stock levels have been ringfenced - are the products within the bundle simple or do they have variant options? If the products within the bundle have variants, it’s likely this is not the right approach. However, it could still be configured successfully if the total number of variants stays within Shopify's maximum limitations of 100 variants and up to 3 options. 

• Do component products need to maintain their stock levels (eg a single inventory number whether sold singularly or within the bundle)?

• If so, is there integration into ERP, and is this inventory level shared across any other channels too - such as eBay/Amazon being fulfilled from the same stock? 

• At what point are these values updated and is there any risk of sync issues within orders - for example does the stock level need to update within Shopify or within the ERP and then feeds back to Shopify.

• If the inventory is shared, then how should an OOS component products be handled? Is the whole bundle unavailable (if so, make sure to implement the ability for back in stock notification to the customer). Or can alternative products dynamically be slotted into this bundle to maintain its availability until that item is back in stock. The answer to this might be different depending on the context of the business and what is being sold. 

Based on all of these considerations, there should now be a decision of how these bundles are most suited to being setup in the backend of Shopify - either as a simple product, a product with variants for bundle options, or a group of individual products that are pulled into the frontend and configured as a single line item. With that confirmed, we can explore how best to render on the frontend. There are a few different routes to consider for this:

Extra Functionality from existing 3rd Party tech

Depending on the tech already powering the store(s), it could be a feasible option to extend some functionality from 3rd parties that are already in use. For example, if personalisation or product recommendations are already being delivered via Nosto or Rebuy, they can also power the bundling aspect. This could minimise the impact on performance compared to introducing new Apps, reducing the amount of new javascript & bloat being added to the codebase. On average they come in at a higher cost than some bundle only Shopify Apps, but if they are in budget - both of these examples deliver really strong implementations.

Example using Nosto:

https://modli.co

The functional benefits of implementing this way are that they can be intelligently dynamic, utilising the same logic behind product recommendations. So handling Out Of Stock items within a bundle is not an issue, and can be dynamically replaced with a relevant alternative. There also would be no concern around whether the line items within a bundle were simple products or had variants.

Extra Functionality from existing ERP

As already touched on, if an ERP system exists within the store architecture then this needs consideration when it comes to inventory management. However, there is opportunity (depending on the ERP) to utilise it for some of the complicated logic around inventory management. For example, Brightpearl has the concept of Bundles & Assemblies, and Veeqo has a really simple piece of functionality across all pricing plans, which is called Product Kits. 

Using this, you can create a single SKU which from a user journey perspective behaves exactly as a single product typically would - but could have content & imagery focused on all the component parts within it. It is sold as a single line item to the user; and then when this sale gets pushed into Veeqo it has stored all of the ‘component SKUs’ so deducts inventory from each of them individually before pushing these new stock levels back into Shopify. 

So as an example, a store selling kitchen utensils might have a range of 10 products - Chopping Board, Peeler, Grater, Ladle etc - which all have a set inventory level and are each sold onsite. An “Ultimate 10 utensil bundle” product could be created with its own SKU and list of 10 ‘component SKUs’ within Veeqo. This would be displayed onsite and added to cart as a single line item. When this SKU was pushed back into Veeqo as part of an order, it would subtract relevant quantity from each of the component parts, and those updated stock levels would all be pushed back into Shopify.     

Bundling Shopify Apps

A search for the answer on the Shopify App store results in an overwhelming amount of potential options. Some of the key considerations to have in mind before installing an app for this solution are as follows:

• They will generally be the cheapest way of finding a solution to this issue, in some cases a lot cheaper than the alternative approaches of custom development. There are some pricing models in there to be wary of, based around your Shopify plan or volume of orders which are likely to change over time. Also bear in mind these costs tend to be per store, if you are on a multistore setup. But the cost saving against custom development could be substantial. 

• As always with installing apps directly from the app store, there will be an impact on performance which won’t become clear until after it has been configured and in use. Even on a development store it may go unnoticed because of a lack of traffic.

• Bundle can be quite a blanket term, and a significant number of the results were essentially just upsells on a PDP - eg when buying a football shirt, you could upsell in a single click to also get the shorts & socks for a discounted price.

• For this reason, the initial step of defining exactly how the bundling functionality needs to go through to the backend of Shopify is crucial. It is easy to get lost down the rabbithole of Apps, trying to make your requirements fit what an app can deliver rather than having a clear scope and finding the right solution to achieve it. How they handle Out Of Stock, if they’re working with simple products/variants or if they are added to cart as a single SKU or set of SKUs are unlikely to be configurable so ensure they tick all boxes. 

• Depending on which app ticks those boxes, it will be 50/50 how flexible the design & layout will be from a frontend point of view - it may be the case that the look & feel is completely restricted to how the app provides.    

The end result is that there are some good options, if they function in the way you require. There is unlikely to be flexibility in functionality so research and due diligence is important here. Ensure the key criteria are technically achievable and look for working examples of the app in use on other sites. If these boxes are ticked for your requirements, this will be the most cost effective solution available. 

In terms of recommendations here, it really depends on what’s required but Bundles or Bundle Products & Discounts are a good place to start - but Bold Apps have a couple of options that can be used individually or in combination Product Bundles and Product Options, and have a really good CS and tech support team that can help make sure implementation goes as planned. 

Example:

https://www.werchristmas.co.uk

Custom Development - Bundles

If none of the options outlined so far meet your requirements, then developing into the theme bespoke to your project may be the best way to go - so that the functionality and user experience are both tailored specifically to what's needed. Depending on the technical spec, this isn’t always a huge effort (although for clarity it certainly can be) and the end result should be that the implementation is flexible enough to be reused across the site for different bundles.

Technical Approach

When your bundle is acting as a single product - has its own ringfenced stock level and single SKU - this won’t be a major effort. The focus is completely on user experience and how it’s presented on the frontend. An alternate PDP template could be created (eg ‘product_bundle.liquid’) and applied to the relevant Product within Shopify, which might have less prominence on just a single image - and more real estate given to the description or Tags that contain the key USPs of the bundle. Using Tags it could be added as a snippet to relevant product pages and displayed as an upsell. Price savings can be displayed to the user pretty flexibly because it will just be using the standard price/was-price fields rather than anything being dynamically calculated.

When your bundle is required to track inventory across component products, there will be more effort involved in the functional logic. To display the bundle on the frontend, Liquid code within the template will need to pull in each of the products individually (usually via Tagging desired product ID/handle). These products can then be presented as a group with a single add to cart button, or with individual clicks to add each to cart - whichever fits best in context. Discount/pricing would be communicated within that block, and Shopify Scripts used to adjust the pricing to include discounts within the Cart. Finally, within the cart template these bundes could trigger a slightly different behaviour to group them as one line item, as the native behaviour would be to simply list each component product as a separate line item as if they were added to the cart individually - although again in some scenarios this might be preferred. 

In both of the methods above, Tagging is essential for specifying the products within the bundles. If the desired functionality is to be more dynamic or scalable rather than Tagging up product IDs - this could instead pull products from a preset Collection. 

Custom Development - Builders

Custom development to produce a product builder rather than a bundle solution will no doubt be more effort and require further consideration. This route would be taken when there is more unique and specific logic involved, a common reason being options that are dictated by previous selections (for example a step-by-step scooter builder, where a decision on the deck restricts which wheels can then be added in the following step.)

Example:

https://www.skatehut.co.uk/

The desired outcome of this is for the user to end up with a product that is really bespoke and tailored to them. These step-by-step decisions would map to the relevant base variant, and then start to add line item properties to the order - such as colours, patterns, personalised lettering etc. This would all be stored on the order and visible in the backend of Shopify, plus on order emails etc.

And the desired outcome is for the user to make selections from groups of products or options, and ending up with a product or set of products that is tailored to them. This often includes stages to make the selection genuinely unique to that user, such as colour & pattern decisions or personalised lettering. 

Example:

https://www.anyahindmarch.com

A final complexity is that the pricing/discounting rules might vary depending on decisions which have been made throughout the users journey. 

Technical Approach

The builder can start as a base product and be integrated into that product's PDP template - but when the scope is complex it will often be most suited to using a content landing page as the starting point, which will then pull in a range of products that are being used. This also means additional flexibility to manage any of the logic with the use of Shopify Sections, and obviously they can also be utilised to make the whole builder page a much richer experience using supporting content. 

The approach here would be to use Shopify API to pull all of the relevant data from the whole product set being used. This should be structured into a format which can efficiently be accessed to power all of the required logic, harnessing a technology such as VueJS or React to manage that dynamically as a single component. 

All of the functional logic for the user interactions such as selections, validation, and progressing forwards/backwards through a step-by-step process is then completely custom and javascript based. These step-by-step decisions would identify the required base variant, and then for more unique attributes would add line item properties to the order - such as colours, patterns, personalised lettering etc. This would all be stored on the order and visible in the backend of Shopify, plus on order emails etc.

To complete the journey, the final product(s) will be pushed into the cart. Depending on context, this could require the Shopify API again to create a new SKU directly into Shopify. From this point, the user can be redirected to cart or checkout (or continue shopping) and are back into the standard Shopify user flow. 

Key Takeaways

In summary, achieving a bundling or product builder solution within Shopify isn’t as clean as it should be - particularly in comparison to other platforms. But there are a few different methods to accomplish your requirements. The key consideration is to understand exactly how it needs to work from a data structure & order processing perspective - desired URL, sku & quantity management, discounting methods, data captured on the order. This will guide the overall architecture of the solution, with UX and the frontend considerations taking place following that point.