Who actually builds custom Shopify Functions? Do we need an in-house developer or can an agency do it?

What does building a custom Shopify Function actually involve?

Building a custom Shopify Function means writing code that Shopify runs inside its own backend, such as a discount rule at checkout. Shopify Functions "allow developers to customize the backend logic of Shopify," and Shopify ships templates and client libraries for Rust and JavaScript (Shopify developer docs, October 2026).

Shopify supports "any language that compiles to WebAssembly (Wasm), such as Rust, Zig, or TinyGo." It is direct about the trade: "Languages that compile directly to WebAssembly, such as Rust, perform better than dynamic languages, such as JavaScript." A JavaScript author should "expect to run into instruction limits sooner" (Shopify developer docs, October 2026).

That matters for staffing, because it moves the skill off the standard Shopify stack. A team fluent in Liquid, Shopify's theme language, is not automatically a team that ships Rust into a checkout path. Which Function to build first, a discount or a checkout validation for example, is a separate choice among the Function categories.

Which Shopify plan can run a custom Function?

Only a Shopify Plus store can run a custom Shopify Function, because only Plus stores can use custom apps that contain Shopify Function APIs (application programming interfaces). Stores on any plan can use public apps that are distributed through the Shopify App Store and contain functions (Shopify developer docs, October 2026).

That plan rule inverts the usual staffing question. Below Plus, a custom Function app cannot run on your store, so the answer to "in-house or agency" is neither. The answer is a pre-built Function app or a no-code Function builder, and both run on any plan because they are public apps. On Plus, the staffing question is real.

Which Shopify limits decide how hard a Function is to build?

Shopify's resource and input query limits decide how hard a custom Shopify Function is to build, because every Function must fit inside them (Shopify developer docs, October 2026). The instruction count caps how much computing one run may do, and the input query is the request that fetches the data the rule reads.

A discount that reads three product tags and applies a percentage sits far inside these limits. A discount that walks a 200-line wholesale cart against a metafield (custom data) table runs close to them, so it needs a developer fluent in Rust. In our judgment, that difference, more than who writes the code, sets the size of the build.

Why does ownership after launch decide in-house versus agency?

Ownership after launch decides in-house versus agency, because a live custom Shopify Function keeps creating work that someone must be named to do. Shopify records each run's input, output and logs in the Dev Dashboard, its developer console. Its monitoring guide lists 12 error types and describes no merchant-facing alert (Shopify monitoring guide, October 2026).

That leaves three standing jobs:

1. Change the rule. Every tier change merchandising asks for lands on whoever owns the code.
2. Keep the Function API (application programming interface) version current. Shopify releases a new version every three months and supports each for at least 12 months (Shopify developer docs, October 2026). A Function on an unsupported version "has been removed from all merchant stores" (Shopify monitoring guide, October 2026).
3. Answer the failures. Somebody has to build an alert, receive it and fix the rule mid-sale. Deploi's record on Function observability scores that work CUSTOMIZE (October 2026).

So the real staffing question is who changes the discount tiers when merchandising changes them, and who finds out when the Function silently stops applying them. A shipping-rate Function that needs a deploy for every new location shows that question left unanswered. What the three jobs cost against an app subscription decides whether to build at all.

Which staffing model fits: in-house, agency or both?

Four staffing models fit a custom Shopify Function, and the right one depends on how often the rule changes and who already owns checkout.

1. In-house, when the rules change often and someone already owns checkout. In our judgment, a rule that changes more than three or four times a year turns every agency request into a queue, so marketing stops asking. A developer who owns the checkout path, writes Rust or will learn it, and sits near merchandising is then the cheapest long-run answer.
2. An agency, when the work is bounded and dated. Porting the rules that Shopify Scripts ran until Scripts stopped on 30 June 2026 is the clearest case (Shopify Help Center, October 2026). Deploi's Scripts-to-Functions record scores that port BUILD when the rules still earn money. What an agency charges for one discount Function depends on the written rule.
3. An agency to build, an in-house owner to operate. In our judgment, this model fails least. The agency ships the Function, the alerting and a runbook, the written steps for when the rule fails. A named person in your business owns the numbers, the deploy and the alert; without that person, the model degrades into a bounded agency job with a longer invoice.
4. Buy instead, and staff nobody. A public App Store app that already expresses the rule needs no developer at all.

When should you not hire anyone to build a Function?