The operational layer Shopify leaves to you
An internal commerce platform running across four ecommerce brands: merchandising automation, pack sizes, stock-limited campaigns with sale countdowns, checkout and fulfilment rules, and lead operations in one configurable application.
Requirements that sat between Shopify and how the business actually ran
The same shape of request kept arriving: keep related products current without maintaining them by hand, sell pack sizes without breaking inventory, run stock-limited sales with real limits, change delivery options when something is backordered, offer an alternative product at a price the checkout will honour, turn storefront forms into internal workflows.
Each one on its own meant manual administration, another SaaS subscription, fragile theme logic, or another round of custom development. So instead of an app per problem, one configurable application the ecommerce team could operate themselves.
Managed in one place, enforced where it counts
Shopify’s checkout cannot read the application’s own database, so any rule it has to apply must be published into Shopify first. The full configuration, history and state stay in PostgreSQL where they can be managed and reported on; only the part checkout needs goes across.
Merchants configure everything in an app inside Shopify Admin. The storefront and checkout handle how it looks. Shopify itself applies the rule, which is what makes it hard to bypass, or to break by accident with a storefront change.
Related products are worked out from Algolia’s recommendation model and written onto the product ahead of time, so a page shows them the moment it loads rather than waiting on a request once it is open.
Six decisions that shaped the build
Configure richly, project narrowly
Merchants need somewhere flexible to set rules up; checkout needs something small and fast to apply. Keeping the full version in the database and publishing only what checkout uses gives both, without slowing the storefront down.
Enforcement and explanation are one feature
When a cart contains backordered stock, a Function removes the delivery services that cannot serve it and a checkout extension tells the customer why. Silently hiding a shipping method would satisfy the requirement and confuse the buyer.
Packs linked to unit inventory, not new SKUs
The pack tool builds pack sizes on Shopify’s native product-component relationships, so a pack of ten still draws on the same stock as a single unit. The whole structure can be reverted to the original product.
The browser never decides a discount
A promotional price is never taken on trust from the storefront. Shopify re-checks every offer against the rules the application set before it is applied, and against the product actually in the cart.
Several changes, no way to undo them as a group
Building packs takes several separate changes to a Shopify product, with no way to undo them as a group. Each step confirms what it created and respects Shopify’s own limits, so a failure halfway through leaves a product that can be repaired rather than a broken one.
Webhooks for speed, reconciliation for truth
Webhooks update campaign allocations immediately; scheduled jobs correct the drift left by missed events and partial failures. Order processing deduplicates, so a repeated delivery cannot decrement the same campaign twice.
What the tools produce on the storefront
One platform instead of a subscription per problem
The ecommerce team manages related products, pack sizes, campaigns, checkout rules and lead workflows themselves, without a developer in the loop and without another third-party service for each requirement.
A capability built once is available to every brand on the platform, configured differently rather than rebuilt. Recommendations, previously maintained by hand, now stay current on their own.
Trade-offs
Store-specific configuration and extension variants were quicker to ship as explicit deployments than to generalise. That was the right call at four stores; it is more configuration surface to maintain with every store added.
Letting Shopify apply the rules means accepting its limits: no database access during checkout, and every rule that matters has to be simple enough to publish into Shopify in the first place.
What I would do differently
The application grew from a recommendations tool into a toolbox, and the boundaries between features follow that history rather than a plan. A few of them would be drawn in different places today.
I would settle how configuration gets published into Shopify once, up front, and hold every feature to it, instead of arriving at the same pattern feature by feature.
Addex Group The operational layer Shopify leaves to you
An internal commerce platform running across four ecommerce brands: merchandising automation, pack sizes, stock-limited campaigns with sale countdowns, checkout and fulfilment rules, and lead operations in one configurable application.
Requirements that sat between Shopify and how the business actually ran
The same shape of request kept arriving: keep related products current without maintaining them by hand, sell pack sizes without breaking inventory, run stock-limited sales with real limits, change delivery options when something is backordered, offer an alternative product at a price the checkout will honour, turn storefront forms into internal workflows.
Each one on its own meant manual administration, another SaaS subscription, fragile theme logic, or another round of custom development. So instead of an app per problem, one configurable application the ecommerce team could operate themselves.
Managed in one place, enforced where it counts
Shopify’s checkout cannot read the application’s own database, so any rule it has to apply must be published into Shopify first. The full configuration, history and state stay in PostgreSQL where they can be managed and reported on; only the part checkout needs goes across.
Merchants configure everything in an app inside Shopify Admin. The storefront and checkout handle how it looks. Shopify itself applies the rule, which is what makes it hard to bypass, or to break by accident with a storefront change.
Related products are worked out from Algolia’s recommendation model and written onto the product ahead of time, so a page shows them the moment it loads rather than waiting on a request once it is open.
Six decisions that shaped the build
Configure richly, project narrowly
Merchants need somewhere flexible to set rules up; checkout needs something small and fast to apply. Keeping the full version in the database and publishing only what checkout uses gives both, without slowing the storefront down.
Enforcement and explanation are one feature
When a cart contains backordered stock, a Function removes the delivery services that cannot serve it and a checkout extension tells the customer why. Silently hiding a shipping method would satisfy the requirement and confuse the buyer.
Packs linked to unit inventory, not new SKUs
The pack tool builds pack sizes on Shopify’s native product-component relationships, so a pack of ten still draws on the same stock as a single unit. The whole structure can be reverted to the original product.
The browser never decides a discount
A promotional price is never taken on trust from the storefront. Shopify re-checks every offer against the rules the application set before it is applied, and against the product actually in the cart.
Several changes, no way to undo them as a group
Building packs takes several separate changes to a Shopify product, with no way to undo them as a group. Each step confirms what it created and respects Shopify’s own limits, so a failure halfway through leaves a product that can be repaired rather than a broken one.
Webhooks for speed, reconciliation for truth
Webhooks update campaign allocations immediately; scheduled jobs correct the drift left by missed events and partial failures. Order processing deduplicates, so a repeated delivery cannot decrement the same campaign twice.
What the tools produce on the storefront
One platform instead of a subscription per problem
The ecommerce team manages related products, pack sizes, campaigns, checkout rules and lead workflows themselves, without a developer in the loop and without another third-party service for each requirement.
A capability built once is available to every brand on the platform, configured differently rather than rebuilt. Recommendations, previously maintained by hand, now stay current on their own.
Trade-offs
Store-specific configuration and extension variants were quicker to ship as explicit deployments than to generalise. That was the right call at four stores; it is more configuration surface to maintain with every store added.
Letting Shopify apply the rules means accepting its limits: no database access during checkout, and every rule that matters has to be simple enough to publish into Shopify in the first place.
What I would do differently
The application grew from a recommendations tool into a toolbox, and the boundaries between features follow that history rather than a plan. A few of them would be drawn in different places today.
I would settle how configuration gets published into Shopify once, up front, and hold every feature to it, instead of arriving at the same pattern feature by feature.