If your a merchant who needs to MVP what I outline below contact me.
That includes customizations for relating standalone products(flat product model) as if they were still variants of each other.
What is the goal here ,why move to shopify if it cannot smoothly mesh with the businesses current product information architecture.
For example if you only care about checkout, this entire problem could be inverted by using the buy-button sdk on existing business websites wherein you only generate products in shopify on demand when customers access them, JIT products; in a way bypassing the 50k+ variant creation behavior or needing to modify shopify themes. And only needing $9/mth for the shopify part.
Big caveat: the below is ONLY in the context of single channel with the online sales channel(website) having a heavily customized theme.
If you need to be multichannel serious thought needs to be given before implementing a flat product information architecture (i.e. no variant-options just the single default variant that is a product)
If multichannel ,through shopify , dictates variant-options get Shopify Plus for massive inventories.
Currently I have over 11,500 products with total of over 250,000 variant combi.... and Shopify plus is just to expensive for me at $2000 per month
Business wise that's a lot of inventory to have that's not capable of generating enough revenue to justify enterprise level conveniences like checkout-discounts, flow automation, increased api limits, etc. If your automatic dropshipping sure why not /shrug ; If not dropshipping you should examine that as a scalability bottleneck first. Before doing any ETL or migration try to streamline things at least even with simple ABC analysis. Large inventories require good investment in marketing, UX, and navigation otherwise your managing a lot of noise.
@Armen_A323 wrote:
How it will work would be something like this. We would have all of the product information in the Shopify and option will be stored in Amazon cloud database we will then connect that product to this database to pull options for that specific product and post it for the customer to select.
Store the external-options on the product-variants themselves as metafields, or metafield definitions. Then the only left is maintaining sync if for some reason there is a database or store hosted on another platform. Having to make customers-browser fetch external-options for every variant for a 250k inventory is massive perf hit in aggregate. If your switching to shopify you don't want your legacy factors to be a bottleneck on a platform that can scale. There's also using app-proxies so instead of ajax fetching the options your serving the product render itself, but again performance matters here.
Regardless when supplanting variant-options with some other data any theme you use on shopify will need to be heavily customized and maintained. There are also some themes with features specifically reliant on things like the variant options object, automatically losing theme features.
Technical - It can be as simple as replacing variant.option with variant.metafield.option1 in templates liquid but alot of themes are over entangled with heavy javascript complicating this.
A flat product-model also means also means any apps based on an assumption of variants will not work off-the-shelf and maybe never will.
- .. over 11,500 products .. over 250,000 variant combination of colors and sizes (only 2 options)
- ..most products have less than 100 but around 160 have over.
- ...Shopify limits on variants .
- ..move all our product information to Shopify but without variations so this will leave us under 50k limit.
- ..I am using theme 2.0 ... product page I want to implement a code to call or pull or request..the options for those products
- .. can use Amazon cloud database to call and post on the specific product page using the product title or Handel.
- ...similar to how BOLD app options are but with this method we will be able to control our inventory levels and we will not have this limit.
#1 & 2 If an option does not affect an intrinsic property like the price, or sku use line-item properties to get customers option choices.
#3 & 4 Current limit is 100 variants per product, once 50k variants exist on a store there is a daily creation limit of 1k(without shopify Plus) over the api. Note here how every product is 1 variant at minimum.
https://help.shopify.com/en/manual/products/variants/add-variants#:~:text=Stores%20with%2050%2C000%2....
#4 If you have 250K variant combinations (#1) that does equate to being able to be under 50k variants if there is only 1 option per product.
#5 Crudely https://community.shopify.com/c/shopify-design/product-pages-get-customization-information-for-produ... though that will need to be modified for any themes specific structure.
#6 with the apis you would be using the variant ids under the hood, though really just store the info on shopify and only use something like an amazon DB for sync'ing on a schedule. (I think both parts of this could even be done with an app like usemechanic to skip having to manage your own app infrastructure)
#7 use one app for handling product options and another to sync inventory, or a scriptable app like usemechanic. Doing both in a custom built app is possible but it can be saner to exhaust off-the-shelf solutions by making an MVP with existing apps/services to better crystalize what's needed and why; i.e. build the req's for a custom app.
