Shopify Development · focused work
Shopify Functions development
A Function is a small program that runs inside Shopify at the moment an order is being calculated. It can decide a discount, hide a delivery option, rename or remove a payment method, block a checkout that cannot be fulfilled, or transform cart lines for a bundle. Because it executes on the platform, the rule applies the same way no matter where the order comes from.
This is the right work if
- The promotion the business runs cannot be expressed with the built-in discount types
- Delivery options need to differ by product, destination or customer group rather than by weight alone
- An app is applying a discount in the browser and it is recalculated or lost at checkout
- Trade customers need quantity breaks that must never reach retail shoppers
- Checkout has to refuse combinations the business cannot fulfil, such as restricted goods to some regions
What it is
What Functions are used to build
Functions are compiled to WebAssembly, delivered inside a Shopify app and configured through metafields or the app's own admin screens, so a merchant can move a threshold or swap a product list without a developer. Each Function API has a defined input query and a defined output. There is no network access and no storage inside a Function, which means everything it needs has to arrive in the input, and that constraint shapes the design more than the choice of language does.
The usual work is pricing and eligibility logic the native rules cannot express: tiered and bundled discounts, quantity breaks that apply only to particular customers, delivery options hidden or reordered by address, product or customer tag, payment methods restricted for certain orders, validation that stops a checkout containing something the business cannot ship to that destination, and cart transforms that combine components into a bundle line. Availability of the individual Function APIs varies by plan, so scoping starts by confirming what the store can actually use, then by writing the rule precisely enough that two overlapping promotions have a defined outcome.
How it is done
The work, in order
What changes
- Pricing and eligibility rules apply the same way wherever the order is created
- Merchants adjust thresholds and product sets without waiting for a deployment
- Discounts are calculated by the platform instead of being applied in the browser
- Orders the business cannot fulfil are stopped before payment rather than after
Confirm what the plan allows
Check which Function APIs the store can use before designing anything, because availability differs between plans and a rule scoped around an unavailable API turns into an app subscription or a compromise late in the project.
Write the rule as inputs and outcomes
Set down every input the decision depends on and the result for each combination, including what happens when two rules could both apply and which one wins. Ambiguity left here becomes a support ticket about an unexpected price after the promotion is live.
Design the configuration surface
Decide what a merchant changes without a deployment: thresholds, product collections, customer tags, dates. Hold those in metafields or an app screen with validation, so a mistyped value is caught in the admin rather than at the point of order calculation.
Keep the input query narrow
Request only the fields the rule reads. Functions run under execution limits on every cart calculation, so a query that pulls a wide slice of the cart and customer costs time on every change a shopper makes, and it is the usual reason a Function starts timing out on large carts.
Test the awkward carts
Try mixed carts, stacked discounts, subscriptions, gift cards, multiple currencies, local pickup and quantities exactly at each threshold boundary. Most Function defects appear at boundaries and in combinations nobody listed in the original requirement.
Deploy through the app and watch it
Release as a versioned app, then monitor the run logs for failures and execution time, and re-test after each platform API version change. A Function that fails silently leaves the order calculated without the rule, which is easy to miss in a busy week.
Platform notes
Shopify
A Function has to be delivered inside an app, which can be a custom app built for the single store, so there is always an app to install, version and maintain even when the logic is a few lines long.
Shopify Plus
Some of the Function APIs, particularly those that change delivery and payment presentation, are tied to the higher plan, so the same business rule can be a Function on one plan and a manual process on another.
What can a Function do that a built-in discount cannot?
Anything conditional on a combination the discount editor does not express: quantities across a set of products, customer tags, cart composition, date ranges layered with membership, or a price that depends on what else is in the basket. The native types handle common cases well and stop where the conditions get compound.
Can a Function look up a price from another system?
No. Functions have no network access, so any external data has to be brought in beforehand, usually by syncing it into metafields on the product, customer or company record. That sync becomes part of the build and needs its own schedule and failure handling.
How do Functions behave when an app also applies discounts?
Both can run and the order of application matters, so the combined result should be tested rather than assumed. Where two mechanisms can discount the same line, decide which one owns that case and configure the other to stand down, otherwise the total will surprise someone.
Do Functions replace the older scripting approach?
They are the supported route now, and they cover a wider set of moments than checkout alone, since they apply wherever the order is calculated. Stores that carried older customisations have generally rebuilt them as Functions, which is also an opportunity to simplify rules that grew over time.
Related work and answers
Find the leak.
A free Growth Analysis ranks what your store should fix first, by revenue at stake.