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?

Is the per-location update a cost of Shopify Functions or of how the code was built?

The per-location update is a cost of how the custom shipping code was built, not of Shopify Functions. Whoever built it wrote location identifiers into the code as constants, so every new warehouse means a code change, a build and a deploy. Code that reads its locations from settings, such as a metafield (a custom data field), turns the same change into a data edit. Who should build and own custom Shopify Functions is a separate decision from what the code costs when locations change.

If you are living the first row, price a refactor to the second row before a migration back to native rates. In our judgment the refactor usually costs less, because it keeps whatever the code does that native rates cannot.

What can custom code do to shipping rates on Shopify?

Custom rates for shipping to an address come from a carrier service, not from a Shopify Function. A carrier service is an app endpoint that returns real-time rates. For each request, Shopify sends it the origin address of the shipping location, the destination and the items (Shopify developer docs, October 2026). Carrier-calculated shipping is available on Advanced and Plus, and Grow stores can add it for a monthly fee or with annual billing (Shopify Help Center, October 2026).

For delivery options that already exist, the Delivery Customization Function can rename, sort and hide them, and a store can activate up to 25 (Shopify's Function reference, October 2026). Shipping discounts belong to the Discount Function instead, per the same reference. So custom code that prices shipping per location is a carrier service. A carrier service already receives the origin address with every request, which means it can look that location's rates up in settings instead of in code.

Deploi's Build vs. Buy record on shipping rate logic splits the work the same way: native rates for simple offers, a delivery-customization Function to hide, rename and reorder, and carrier-calculated apps for multi-origin complexity (October 2026).

What does a new location cost in Shopify's native shipping settings?

A new location costs an admin edit in every shipping profile it should ship from, and no developer. Most stores still use shipping profiles (Shopify Help Center, October 2026). Carrier-calculated rates sit in the same profile zones (Shopify Help Center, October 2026), so custom rate code needs that edit too. Shopify's shipping profiles page defines a profile as "a set of shipping rules for specific products and locations," and a store can create up to 99 custom profiles beside the general one. Inside each profile, location groups carry their own shipping zones and rates. A new location joins every profile automatically, but in the "Not fulfilling from" section (Shopify's fulfillment locations guide, October 2026). No rates apply there until someone adds the location to a location group.

Native shipping is changing too. In Shopify's newer model, shipping options by market, each rate uses location conditions to set the locations it ships from (Shopify's upgrade guide, October 2026). That model is in early access for certain stores, so check which model your store runs before you price a new location.

Which shipping rules still need code beyond native settings?

Shipping rules still need code beyond native settings, yours or an app's, when a rate depends on a fact native settings do not model. Native rates already cover product groups, destination zones and shipping locations, plus price-based and weight-based tiers (Shopify Help Center, October 2026). In our judgment most custom rate logic fits those, so name the fact that does not:

• The price depends on package dimensions, the mix of items or a delivery date. That is work for a carrier service, an app that returns live rates, because Shopify sends it every item with its quantity, weight and price (Shopify developer docs, October 2026).
• The offer depends on who the customer is, or an option must be hidden, renamed or reordered. That is a Delivery Customization Function, which can hide options for certain products or customers (Shopify's Function reference, October 2026). Public App Store apps run one on any plan; a custom app you own needs Shopify Plus (shopify.dev, October 2026).
• The rule decides which location fulfills the order. That is the Order Routing Location Rule Function, a beta that Shopify opens to Plus merchants by request only (Shopify's Order Routing reference, October 2026). Which Function category to build first covers when that request is worth making.

How do you decide between refactoring the code and moving to native rates?

Move to native rates only if every case reduces to product, destination, location, order value or weight; otherwise, refactor the code. Five steps settle it, and each can end the question early:

1. Write the rate rule out. If every case fits those five facts, native settings carry it: migrate and delete the custom code.
2. Name the fact that does not fit. That fact is the only reason the code exists, and the only thing it should do.
3. Check the design. If the code reads locations as constants, refactor it to read them from settings before you consider migrating. Deploi's Function settings record scores that settings layer CUSTOMIZE (October 2026).
4. Count your real change rate. Multiply the locations you add a year by the cost of one deploy (Deploi arithmetic). If that number is small, this was never the expensive problem.
5. Price the monitoring either way. A carrier service, the app that returns live rates, gets no retry. An error or timeout shows another eligible rate or Shopify's default backup rates (Shopify Help Center, October 2026). Backup rates miss bugs: a service that answers with a success code shows its wrong prices, or none if it returns an empty list (Shopify developer docs, October 2026). For a Shopify Function, the monitoring guide describes no merchant-facing alert (shopify.dev, October 2026), so Deploi's observability record scores alerting CUSTOMIZE (October 2026).

When is the native rate table the better long-term choice?

The native rate table is the better long-term choice when the custom shipping code does nothing native settings cannot, or when operations cannot change rates without a developer:

• When the code does what profiles already do. Some was written before the merchant knew profiles could do it. Some came from a Shopify Scripts port that skipped the audit. Deploi's Scripts-to-Functions record starts every port by marking each rule keep, change or drop (October 2026).
• When operations cannot self-serve. A rate change that needs a developer does not happen during peak, which is when it matters.
• When the store is below Shopify Plus and relies on a public app. You depend on the vendor's settings anyway, so native profiles plus a delivery customization app is the simpler stack.