Club and school kit retailer
a collection-availability scheduler running on the client's own app subdomain (pointed there on 2026-07-22), Carrier Service delivery rules with a no-code condition builder, and a storefront countdown.
Custom Shopify apps, checkout & paymentsOpen demo
Discounts and Delivery Logic Native Settings Can't Express: Shopify Functions
Shopify Functions for delivery and discount logic the native settings cannot express — configuration kept on metafields and a checkout that fails safe.
- For
- Shopify merchants
- Checked
Sounds familiar?
Tick what applies to you
How I solve it
What I build
I build Shopify Functions — delivery and discount logic that runs inside checkout, where native settings stop and theme hacks break. The configuration lives on metafields, so the rule can change without a redeploy. My public demo covers a Discount Function with its config on a metafield: missing or invalid config returns no discount in local tests. For a store build, I test on a dev store with synthetic config first, and publish the code only with your approval.
The closest delivered work I have is a Carrier Service rule engine for a real retailer — adjacent, honest proof that I build this kind of checkout logic, even though that one runs through Carrier Service rather than a Function.
The process
How it works
6 steps. Scope and a fixed price are agreed before the first one.
-
Write the rule the way a merchant would say it, and find the boundary: what a Function can and cannot do inside checkout.
-
Split the rule into config and code: put everything that changes on metafields.
-
Build the Function and the small admin surface that edits the config.
-
Fail safe: on missing or invalid config, return no rate or discount rather than break checkout.
-
Test against a matrix of cart cases on a dev store with synthetic data, and record each case.
-
Publish the demo repository on your approval, with the config and a rollback.
Handover
What you get
- A Function that runs your rule inside checkout, where native settings cannot go.
- The changing part kept on metafields, so a rule change is configuration, not a deploy.
- A fail-safe default: invalid config returns nothing instead of breaking checkout.
- A test matrix across cart cases, run on a dev store with synthetic data.
- The demo repository, published on your approval, with the config and a rollback.
Built with
- Shopify Functions (delivery and discount)
- metafields for configuration
- Shopify CLI and the Dev Dashboard
- the app's admin surface
- The public demo is tested locally with synthetic carts
Proof
Done before, with dates and numbers
Open demo An open build on synthetic data that shows the method.
Before → after
Before, a club and school kit retailer’s checkout could not express its three delivery cases — single-collection pickup, mixed-cart paid delivery by zone, and delivery-only collections — in native settings. After, a Carrier Service rule engine resolved them from merchant-defined rules; that build ran from 2025-10-22 to 2025-11-03.
-
-
Collection-aware shipping rules app
a priority rule engine resolving three delivery cases from merchant rules, with country-specific pricing profiles and a fail-safe on bad input.
[He] made the perfect app for us and is brilliant to work with.
What you can look at
I built a Discount Function demo with synthetic data: market thresholds and tag exclusions configured through a metafield. You can read the demo repository on GitHub, including its local tests and WASM build; it does not cover delivery rules or an installed Shopify app.
The demo runs locally with synthetic data. Client details are anonymised. I am the founder of Fixel Pixel.
Price and timeline
What it costs and how it runs
The demo is built first, so you can read the approach before committing. A bounded rule is a Focused Fix from USD 450; a Functions-and-app build is a Custom Engineering Project from USD 1,500, scoped and quoted in writing after we agree the rule and its failure behaviour.
QuoteFixed before work starts
- Price
- Focused Fix from USD 450 for a bounded rule, or a Custom Engineering Project from USD 1,500 for a Functions-and-app build, scoped and quoted in writing. Discussing the task is free.
- Timeline
- The public demo runs locally with synthetic config. A real build is scoped and quoted in writing after the rule and its failure behaviour are agreed.
- First step
- Describe the task. I reply within one working day, free, and tell you which option fits — or that you can fix it yourself.
A note from Daniilbefore you decide
When you don’t need this
If a native discount or shipping setting already expresses your rule, use it. A Function is worth building when the rule is genuinely outside the settings — collection-aware, metafield-driven, or date-driven — and it must run inside checkout. If the rule is only cosmetic, a theme change is cheaper, and I will tell you that rather than build more than you need.
— Daniil
Questions
What people ask about this
Why a Function instead of an app?
A Function runs inside checkout, so the logic cannot be skipped at the final step. An app is still needed to hold the configuration and the admin screen, but the rule itself executes in checkout.
Can we change the rule without calling you?
That is the design. Whatever changes — thresholds, collections, dates — lives on metafields, so it is edited in the app without a redeploy.
What happens if the config is wrong?
The Function fails safe: it returns no rate or discount instead of breaking checkout. A bad rule is a missed promotion, not a broken store.
Does this replace a full discount or shipping app?
No. It replaces the specific rule your business actually runs. If you need a broad promotion engine, that is a different tool and probably a larger build.
Is the demo real or illustrative?
The public demo is a Discount Function with synthetic config, tested locally including its WASM build. It does not cover delivery rules or a dev-store checkout.
More like this
All situations
Have a task like this?
Describe your taskThe first answer is free, within one working day. Or write directly: next@taskfordaniel.com