Shopify Functions: real examples worth building

Shopify Functions are small pieces of custom code that run inside Shopify's own back end to change core commerce logic — discounts, cart and checkout validation, delivery and payment options, and bundles. They execute in milliseconds with no external server in your checkout and no per-order app fee. The catch: the checkout-facing ones require Shopify Plus.

I am a senior Shopify developer in Delhi, and I build Functions for D2C brands on Plus — usually to replace a stack of overlapping apps with a few lines of owned logic. This is the honest version: the use-cases actually worth building, when a Function beats an app, and where an app still wins.

What is a Shopify Function, in plain terms?

Think of your store's back end as a set of decisions Shopify makes on every order. What discount applies? Is this cart allowed to check out? Which shipping methods show, and in what order? Which payment methods appear? How does a bundle break down into its components? Historically those decisions were fixed, or you bolted an app onto them.

A Function lets you replace one of those specific decisions with your own code. Shopify calls your Function at the right moment — say, when the cart recalculates or checkout loads — passes it the relevant data, and uses whatever your code returns. It runs on Shopify's infrastructure, compiled to WebAssembly, inside a strict millisecond execution budget. There is no server of yours in the loop, nothing to keep online, and nothing calling out across the network mid-checkout.

That last point is the whole reason Functions matter. An app that customises checkout usually does it by calling its own server while your customer waits. A Function does it natively, in-process, in milliseconds. It is faster, more private, and it does not go down when the vendor's server does.

Which Functions need Shopify Plus?

This is the first question to settle, because it decides your budget. The Function types split cleanly:

The pattern: anything that edits checkout behaviour needs Plus, because non-Plus stores cannot touch checkout logic at all. Discount and bundle Functions are the exceptions that run everywhere. So if your entire reason for reaching for Functions is custom delivery or checkout rules, the real project is "move to Plus and build the Function," and you should budget for both. If you are weighing that jump, I have written a full breakdown of when it is worth upgrading to Shopify Plus.

Custom discount Functions: the best starting point

Discounts are where most brands should start, because discount Functions run on every plan and they replace the most expensive category of app.

The default Shopify discount engine handles simple cases — a flat percentage, a fixed amount, basic "buy X get Y". The moment your promotion has any nuance, you reach for an app, and that app sits in your critical path forever. A discount Function reproduces that logic natively. Real examples I have built:

• Tiered cart discounts. Spend ₹2,000 get 5% off, ₹4,000 get 10%, ₹6,000 get 15% — computed on the actual cart, applied automatically, no code needed at checkout.
• "Buy 2 get the cheapest free" across a specific collection, respecting which items qualify and which do not.
• Member or wholesale pricing driven by a customer tag or metafield, so logged-in members see a different discount than guests without a second price list.
• Exclusion logic — first-order codes that do not stack with sale items, or a discount that ignores gift cards and already-marked-down products.

Each of those is often a paid app doing one job. A Function collapses several of them into one owned piece of logic with no monthly fee. For a growing D2C brand running frequent promotions, that is real money and one fewer vendor in the checkout path. Discounts also interact with GST and invoicing in India, which is worth getting right — I cover the tax side in Shopify Payments, COD, and GST for Indian stores.

Checkout and cart validation: stop bad orders before they happen

This is a Plus-only Function, and it is one of the most useful. A validation Function inspects the cart or checkout and can block it with a message you control. That sounds small until you list what it prevents:

• Minimum order value for certain zones or products — "wholesale orders must exceed ₹25,000."
• Quantity limits on limited-drop or high-demand SKUs, so one buyer cannot clear your stock.
• Address or PIN-code rules — refuse checkout to regions you do not ship to, or require a phone number for COD.
• Mutually exclusive items — block a cart that combines products that cannot ship together.
• B2B-only gating — only allow certain SKUs to check out for tagged wholesale accounts.

Before validation Functions, brands did this with apps that ran client-side JavaScript on the cart — easy to bypass, and gone the moment a customer went straight to checkout. A validation Function runs server-side inside Shopify, so the rule is enforced at the source and cannot be skipped. If you run wholesale and retail on one store, this pairs naturally with native B2B — I go deeper in running D2C and B2B on one Shopify Plus store.

Delivery and payment customization: control what customers see

These two Plus-only Function types are close cousins. Both take the list of options Shopify would show at checkout — shipping methods, or payment methods — and let you reorder, rename, or hide them based on the cart, the customer, or the destination.

Delivery customization examples:

• Hide "Standard" shipping when the cart qualifies for free express, so customers do not accidentally pick the slow, paid option.
• Rename methods to something clearer — "Delivered in 2–3 days (Delhi NCR)" instead of a carrier's raw label.
• Reorder by margin or speed, surfacing the option you want most customers to take.
• Hide COD above a cart value where returns risk gets expensive, or below a minimum where the COD fee eats your margin.

Payment customization examples:

• Hide COD for out-of-serviceable PIN codes or for flagged high-risk carts, cutting your RTO (return-to-origin) losses.
• Reorder payment methods to put prepaid UPI and cards above COD, nudging prepaid orders.
• Hide a payment method for specific products — for example, no COD on made-to-order or high-value items.

For an Indian D2C brand, COD control alone can justify the whole project. RTO on COD orders is one of the biggest silent margin leaks in the market, and a payment Function that hides COD for risky carts or expensive PIN codes directly reduces it — natively, with no app fee per order.

Bundles with cart transform Functions

Bundles are the fourth big use-case, handled by cart transform Functions, and these run on all plans. A cart transform Function changes how line items appear and expand in the cart.

Two common shapes:

• Fixed bundles — a "starter kit" that a customer adds as one product but which expands into its component SKUs behind the scenes, so inventory and fulfillment stay accurate while the customer sees one clean line and one price.
• Merged line items — combining components into a single displayed bundle for a cleaner cart and correct pricing.

The value over a bundle app is the same story as everywhere else: the logic lives in Shopify, inventory stays truthful because the components are real line items, and there is no monthly fee or external dependency. For a brand whose merchandising leans on kits and sets, an owned bundle Function is cleaner than renting one.

When a Function beats an app — and when it doesn't

Functions are not always the answer. Here is the honest decision, side by side:

Reach for a Function when the logic is core to how you sell, you want it fast and private, and you are happy to own a small, stable piece of code instead of paying a monthly fee forever. Discounts, checkout rules, COD control, and bundles are the classic wins.

Stick with an app when your team needs a no-code dashboard to create and edit promotions themselves, when you want a vendor on the hook for maintenance, or when the feature set is broad and you would rather not build and own all of it. There is no shame in an app — the mistake is running six overlapping apps for logic that three Functions would own cleanly.

The math usually favours Functions once app fees stack up. If you are paying several thousand rupees a month across discount, bundle, and checkout-rule apps, a one-time Functions engagement pays for itself within a year and removes vendors from your checkout. The trade-off is that you now own code — which is exactly why most brands build Functions with a developer on a fixed scope rather than piecing it together in-house.

What building Functions actually involves

For the developer-curious: a Function is deployed as part of a Shopify app you build with Shopify's CLI. You write the logic — most commonly in Rust or JavaScript — it compiles to WebAssembly, and you deploy it to the store. Shopify invokes it at the defined extension point, passes input as a typed query result, and expects a typed output. You then configure it in the admin (for example, activating a discount that your Function powers).

The constraints that matter in practice: a Function must run inside a tight execution budget and cannot make network calls, so all the data it needs must come from the input Shopify provides — cart contents, customer, metafields, and so on. That is a feature, not a limitation: it is what keeps Functions fast and reliable. Most of the real skill is modelling your logic to fit that input cleanly and using metafields well, which ties into a broader Shopify metafield strategy.

What does a Functions project cost?

Functions work almost always happens on Plus, so here is where it sits in my pricing, in INR and USD:

A focused engagement — say, a tiered discount Function plus a COD-control payment Function — lands in the first row. If Functions are part of a full Plus theme build from day one, they are folded into the larger project. And because promotions and rules evolve, most brands that lean on Functions keep a light retainer to iterate them. Every engagement is fixed-price with a written scope and a Definition of Done before any work starts — no open-ended hourly billing.

Note that these are Plus-tier build prices. The Shopify Plus platform subscription itself is separate and negotiated with Shopify (custom pricing well above the standard plans, as of 2026 — confirm current figures with Shopify directly). Functions do not add a platform cost on top; they are code you deploy to a store you already run.

What's next

If you are on Shopify Plus and looking at a wall of apps that Functions could replace — or planning a Plus build and want checkout logic, discounts, and bundles owned rather than rented — the Shopify Plus developer page lays out how I work: fixed pricing, a written scope, and direct access to the person writing the code. Tell me which apps you are trying to retire or which rules you want to enforce, and I will tell you honestly which are worth building as Functions and which are better left as apps.

Start with the specifics of your store on the intake form, and I will come back with a fixed number and a plan within 24 hours.

Related reads

• When to upgrade to Shopify Plus — whether the platform jump is justified for your brand.
• Shopify Plus B2B and wholesale on one store — where validation Functions and native B2B fit together.
• Shopify metafield strategy — the data layer most Functions read from.

Sources

• Shopify — Shopify Functions overview
• Shopify — checkout and delivery customization
• Shopify Plus — platform overview