If our custom shipping-rate Function needs updating every time we add a new fulfillment location, does that ongoing cost make a simpler native rule table a better long-term choice?
A shipping Function that needs a code change per new location was scoped wrong, not chosen wrong. Read locations from configuration and a new warehouse becomes a data edit. Shopify allows up to 99 custom shipping profiles plus the general profile (Shopify Help Center, September 2026), which is the ceiling that decides whether native rules can carry the logic instead.
Fix the premise before you answer the question
"Needs updating every time we add a location" is a property of how the Function was built, not of Functions. There are two designs and they have opposite maintenance profiles.
| Design | New location means | Who does it | When it breaks |
|---|---|---|---|
| Location identifiers as constants in the Function | A code change, a build and a deploy | A developer | Every expansion, forever |
| Location identifiers read from metafields or app configuration | A data edit | Ops | Only when the logic itself changes |
If you are living the first row, the question worth asking your team is whether refactoring to the second row costs less than the migration back to native rules. Usually it does, and it keeps whatever the Function was doing that native rates could not.
What native rules can actually carry
Shopify's native model is shipping profiles: "a set of shipping rules for specific products and locations," with zones and rates configured per location within each profile. A store gets "up to 99 custom shipping profiles" plus the default general profile (per Shopify Help Center, September 2026). Shopify also notes these are transitioning toward a shipping-options-by-market model, and that page did not publish its own limits when we checked, so treat that transition as something to confirm with Shopify before you plan a migration around it.
Ninety-nine profiles is a lot. Most rate logic that people build Functions for is expressible as profiles and zones, and it fails only for one of these reasons:
- The rate depends on something other than product, destination and location. Customer segment, cart composition, delivery date, a surcharge that only applies above a threshold.
- The rule needs to hide an option rather than price one. That is Delivery Customization, a different Function API from a carrier rate.
- The rule needs to control which location fulfills the order. That is Order Routing Location Rule, which is "only available by request for merchants that have a Shopify Plus plan" and requires Partners program enrollment to deploy your own (per shopify.dev, September 2026).
The decision, as a sequence
- Write the rate rule out. If every case reduces to product plus destination plus origin, native profiles carry it. Migrate and delete the Function.
- If a case depends on something else, name it. That one dimension is the only reason the Function exists, and it should be the only thing the Function does.
- Check the design. If the Function reads locations as constants, refactor to configuration before you consider migrating away. That is a smaller project than a rate migration.
- Count your real change rate. Locations added per year, times the cost of a deploy. If that number is small, this was never the expensive problem.
- Price the observability either way. Shopify ships no merchant-facing alert for Function failures and truncates logs at 1 kB (per shopify.dev, September 2026). A shipping Function that fails quietly shows wrong rates or no rates, and no-rates-at-checkout is a conversion outage.
When the native rule table genuinely is the better long-term choice
- When the Function is doing something profiles already do. Some were built before the merchant knew profiles could do it, and some inherited from a Scripts migration that ported logic instead of re-evaluating it.
- When ops cannot self-serve. A rate change that requires a developer is a rate change that does not happen during peak, which is when it matters.
- When the store is below Plus and relying on a public app. You are dependent on the app vendor's configuration surface anyway, so native profiles plus a delivery-customization app is a simpler stack.
When keeping the Function is right
- The rate depends on a dimension profiles do not model, and you can name it in one sentence.
- The change rate is genuinely low. Two locations a year at a small deploy cost is noise.
- The Function is already configuration-driven, in which case the premise of the question no longer applies.
When NOT to decide this during a peak season
Rate logic changes are the highest-risk change class at checkout, because the failure mode is invisible at the code level and expensive at the order level. Move this work between selling seasons.
The Deploi point of view
Our own position, from building on Shopify. Separate from the facts above.
- Our take: make location a configuration input, not a constant, and this stops being a platform question. The recurring cost in the question is a design defect with a cheap fix, and migrating to native rules to escape it also discards whatever the Function was doing that native rules cannot.
- What we’ve seen: shipping Functions carrying logic that profiles already handle are common, and they are usually inherited rather than chosen. A Scripts migration that ported rules faithfully without asking whether they were still necessary is the usual origin story.
- Where we disagree: the standard framing treats this as custom-versus-native, a platform choice. It is a configurability choice, and the same question decides the lifetime cost of every Function a business owns, not just this one.
- What this page adds: the 99-profile ceiling that decides whether native rules can carry the logic, the fact that Order Routing Location Rule is request-gated to Plus merchants, and the constants-versus-configuration distinction that actually causes the recurring cost in the question. The parent asks who builds; this page shows how a build decision made once becomes a bill forever.
Reviewed by Martin Dejnicki, Director of SEO & AI Search. Facts verified 2026-09-14.
Where we worked this out
Our decision records