Most merchants hear "Shopify Functions" and file it under developer trivia. It is closer to the opposite. Functions are the answer to about half the "can Shopify do that?" questions somebody has told you no about, and the reason the answer changed is that the logic now runs inside Shopify’s own commerce engine rather than being bolted onto the page after it loads.
The distinction that matters is where the code sits. Functions decide outcomes: what a cart costs, which delivery options appear, whether an order may proceed. What the checkout page looks like while that happens is a different surface with different rules, covered in checkout extensibility. Nothing in this post will move a pixel of layout, and nothing in that one will change a price.
What a Function actually is
A Function is custom logic that Shopify runs at the moment a commercial decision is made. It is compiled to WebAssembly, which is why it is fast enough to sit in the critical path of a cart calculation, and it can be written in any language that compiles to Wasm; Shopify recommends Rust and ships a JavaScript template for teams who would rather not learn one. None of that matters to a merchant except for the consequence: a Function cannot be blocked, slowed or bypassed by the browser, because it never runs there.
That is the whole unlock. The previous generation of customisation lived in the storefront, which meant every pricing rule and every cart restriction was a script racing the page, visible in source, defeatable by anyone with developer tools open, and liable to break the moment a theme changed. Server-side logic has none of those properties. It is also why Functions feel restrictive at first: each one answers a specific question the platform asks it, and you cannot ask it a different question.
What Functions are allowed to decide
The Function APIs are a fixed list rather than an open door, and reading it is the fastest way to work out whether your requirement is a two-week build or an impossibility. The four merchants ask for most are discounts, delivery, payment and validation, and the full set covers rather more than that:
- Discounts. Cart-line and delivery discounts calculated by your own rules, including the stacking behaviour the native discount engine will not express.
- Cart and checkout validation. Refuse a checkout that breaks a business rule, such as a trade account trying to submit a £186 order against a £250 minimum.
- Delivery customisation. Rename, reorder or hide shipping options based on the cart contents, the destination or the customer record.
- Payment customisation. The same control over payment methods, which is how a store stops offering pay-later on an order worth several thousand pounds.
- Cart transform. Change how cart lines are priced and presented, which is what makes a genuine bundle behave as one line rather than a discount code with good manners.
- Order routing. Decide which location should fulfil an order instead of accepting the platform’s default ranking.
- Fulfilment constraints. Keep items that must ship together in the same group, and force apart the ones that must never travel together.
- Local pickup and pickup point generators. Produce the collection options your operation actually offers rather than the ones the platform assumes you offer.
The plan rule that catches everybody
Here is the part that gets misreported constantly. Functions are not a Plus-only feature in general, and they are not open to everyone either. Shopify’s own wording is precise: stores on any plan can use public apps distributed through the App Store that contain Functions, and only stores on a Shopify Plus plan can use custom apps that contain Function APIs. Read that twice, because it decides the budget before it decides the architecture.
In practice a standard-plan merchant gets Function-powered behaviour by installing an app somebody else built and published, while logic written for your business alone requires Plus. There is no clever route around it, because a custom app is a custom app whether an agency built it or your own developer did. If the requirement is genuinely unique and you are not on Plus, the honest options are to find the closest public app, adjust the requirement, or price the plan upgrade into the project rather than discovering it halfway through.
Scripts are gone, and the deadline has passed
If you were on Plus and had Ruby Scripts running discount or shipping logic, this stopped being a planning question some time ago. Shopify closed editing and publishing of Scripts on 15 April 2026, and Scripts stopped executing entirely on 30 June 2026. A store that treated the deadline as negotiable is now running without the rules it wrote, and that usually surfaces as margin rather than as an error message: the tiered discount that quietly stopped applying, or the shipping method that is no longer being hidden from the customers it was hidden from.
Build one, or install an app?
The default answer is the app, and it should be. A published app carries its own maintenance, its own updates against API version changes, and somebody else’s support burden. Build only when the logic is genuinely specific to your commercial model, when the nearest app forces you to change the business to fit the software, or when you would otherwise be installing a fourth app to do a fraction of what the previous three already do.
That last case is the common one, and it is worth counting properly. Every app installed to express one rule is a permanent line in the monthly costs and a permanent participant in the store, which is the argument the app audit makes at length. One Function replacing three overlapping apps is usually cheaper inside a year and always simpler to reason about. Three Functions replacing one app is a project somebody talked themselves into.
The test for whether this is worth a conversation
Write down the rules your business follows that your store cannot currently express, then cross off every one that is about how a page looks. What remains is the Function backlog. If the list is empty, you do not need any of this and should stop reading. If it has five items and three of them cost you margin every week, it is a build, and the size of that build is decided by the API surface rather than by engineering difficulty.
Scoping it is Shopify development work with a specific shape: somebody has to read the input schema for the relevant Function API and confirm the rule can be expressed at all before anybody promises it. That reading takes an afternoon and saves a quarter. If you have a rule you have been told is impossible on Shopify, get in touch and bring the rule rather than the workaround.
