Should You Build or Buy Shipping Rate Logic on Shopify?
Shipping rate logic on Shopify splits three ways: native conditional rates cover single-origin, threshold-simple offers for free; a delivery-customization Function rebuilds the hide, rename, and reorder logic that died with Shopify Scripts on 2026-06-30; and carrier-calculated rules apps earn their keep on multi-origin and dimensional complexity. Buy the rate plumbing, build the logic layer. An estimated $8,000–$20,000 Function build (Deploi estimate, illustrative) replaces the whole Scripts lane.
Your profile — see how the verdict shifts
- Confidence
- High — The lanes are settled: Scripts died 2026-06-30, Functions are the sanctioned logic surface, and native settings plus carrier plumbing bound the edges, so which lane you're in decides the verdict, not frontier movement
- Reference scenario
- $20M–$100M GMV · single origin · working base rates · agency dev bench
- As of
- August 2026
Decision at a Glance
| Your profile | Verdict | Why |
|---|---|---|
| Single origin, threshold-simple offer | WAIT | Native conditional rates (weight or price, by zone) plus a free-shipping threshold cover this at no extra cost. Spend nothing here until the offer outgrows the settings. |
| Working rates that need logic (hide, rename, reorder) | BUILD | The ex-Scripts lane: a bounded delivery-customization Function encodes the rules once, runs in-checkout with no rate-call latency, and ends the subscription question. |
| Multi-origin, dimensional, or live-carrier rates | BUY | Box-packing algorithms and carrier API upkeep are undifferentiated plumbing. Rating platforms have years of it built, and rebuilding it rarely pays. |
| $75M+ or freight-heavy: rate math as a margin lever | CUSTOMIZE | Buy carrier connectivity, build the blending and rules layer on a custom carrier service: negotiated contracts and routing logic are exactly what preset rule UIs flatten. |
What Shipping rate logic Actually Drives
| Outcome | Impact | How it works |
|---|---|---|
| Revenue — direct | High | Rates appear at the exact moment a shopper decides to pay, so wrong, missing, or inflated options cost completed checkouts directly. |
| Operational efficiency | High | Dimensional and origin-aware accuracy closes the gap between what you charge for shipping and what carriers charge you, otherwise a silent margin leak on every order. |
| Customer experience | Medium | Branded option names and a sensible sort order replace the carrier alphabet soup shoppers otherwise have to decode at the shipping step. |
| Revenue — indirect | Medium | Free-shipping threshold nudges lift average order value only when the rate logic can enforce and message them consistently across zones. |
| Data & insight | Low | Owned quote logs show which options shoppers see and choose, feeding carrier negotiations and threshold tuning. |
Spend ceiling: Size the spend to the charge-versus-cost gap on every order plus the checkouts lost to wrong or missing options. The rule engine itself is commodity; don't fund a bespoke one until rate math moves margin.
What buying enables (top apps)
- + Live carrier quotes, dimensional box-packing, and multi-origin blending working this week — years of carrier-API plumbing you don't have to write
- + A rules UI ops can change without a deploy: thresholds, surcharges, and zone tweaks stay in merchandising's hands
- + Vendor-absorbed carrier churn: when a carrier changes an API, that's the vendor's sprint, not yours
- + Fallback rates when a live quote fails, so checkout never shows an empty shipping step
What building additionally unlocks
- + Logic that executes inside checkout with zero external calls: no rate-provider latency or timeout in the conversion path
- + Rate math tuned to your negotiated carrier contracts and margin targets, not the closest preset a rules UI offers
- + A cost line that stays flat while order volume grows, instead of app tiers that scale with it
- + Rule config as metafields: platform data your admin, Flow, and future storefronts can all drive, not vendor settings
Find Your Verdict in 3 Questions
Do native conditional rates (weight or price thresholds, by zone) fully express your shipping offer?
Yes: Your verdict: WAIT — native settings cover it; spend nothing and revisit when the offer outgrows them.
No: Go to question 2.
Is the gap about creating rates themselves — live carrier quotes, dimensional packing, multi-origin blending?
Yes: Go to question 3.
No: Your verdict: BUILD — a delivery-customization Function rebuilds the hide, rename, and reorder lane Scripts used to own.
Is rate accuracy a margin lever big enough to fund infrastructure — freight, negotiated contracts, fulfillment-network routing?
Yes: Your verdict: CUSTOMIZE — buy carrier connectivity, build the blending and rules layer on a custom carrier service.
No: Your verdict: BUY — a rules app or rating platform has already built the packing and carrier plumbing.
The TCC Scorecard — 12 Dimensions
TCC — Total Cost of Capability: what it actually costs to have this capability over three years, whichever way you get it. Each dimension is scored 0–5 for both paths. How we score →
| Dimension | Buy | Build | Why |
|---|---|---|---|
| Cost | |||
| Acquisition & implementation | A rules app installs in a day though complex rule trees take real configuration time; the Function build is an estimated 2–4 weeks (Deploi estimate, illustrative). | ||
| Recurring fees | Rules apps bill monthly and rating platforms commonly tier by order volume, so success raises the bill; a deployed Function has no subscription line. | ||
| Maintenance & upgrades | The vendor absorbs carrier API churn; your Function needs version bumps on Shopify's roughly six-month API cycle, and rule changes are deploys unless you build a config UI. | ||
| Switching & exit | Rule trees built in a vendor UI rarely export cleanly, so app exit means manual rebuild and re-testing; Function code is yours, though a carrier-service endpoint is infrastructure someone must keep running. | ||
| Risk | |||
| Vendor risk | A rate provider outage at the shipping step can leave checkout with no options unless fallbacks are configured; your own Function has no vendor to lose. | ||
| Security & compliance surface | Live-rate requests send cart contents and destination addresses to a third party on every checkout; a Function runs inside Shopify with nothing leaving. | ||
| Platform-deprecation exposure | Scripts just proved rate logic can die on a date; Shopify retired them in favor of Functions, so the build sits on the sanctioned surface while apps track platform shifts one layer removed. | ||
| Value | |||
| Fit to requirement | Split by lane: apps ship box-packing and multi-carrier depth a Function can't create, while a Function matches your exact logic without renting a whole rule engine for three rules. | ||
| Time to market | An app can rate live orders this week; the Function lands in an estimated 2–4 weeks and a carrier-service engine takes 6–10 (Deploi estimates, illustrative). | ||
| Performance & scale | Third-party rate calls add a checkout-blocking network hop with a timeout failure mode; Functions execute in-checkout with no external call, though a custom carrier service reintroduces that risk on your own infrastructure. | ||
| Data ownership & AI-readiness | Owning the engine keeps quote logs and charged-versus-cost margin data queryable for carrier negotiations; app-side logs are plan-gated exports at best, but this isn't the decisive dimension here. | ||
| Focus & opportunity cost | The Function lane is bounded enough to sit beside feature work; a full carrier-service engine is real infrastructure, so buy that layer unless rate math genuinely moves margin. | ||
The App Landscape
| App | Status | Pricing | Best for |
|---|---|---|---|
| ShipperHQ | Live — Cross-platform rating engine with dimensional-packing pedigree | Feature/carrier-tiered | Multi-carrier, dimensional, and freight-grade complexity |
| Intuitive Shipping | Live — Rules-builder shipping engine covering most Script-era rate logic | Order-volume tiers | Deep rule trees managed from Shopify admin |
| Advanced Shipping Rules | Live — Long-running rules veteran in the category | Tiered | Per-product and per-vendor rate splits and blending |
The Build Path
- Delivery-customization Function: Hide, reorder, and rename the options your rate sources return (PO-box gating, express cutoffs, brand-language names), with rule config in metafields and no network call at checkout.
- Shipping-discount Function: For logic that must move the price rather than the list: threshold promos and customer-segment shipping offers as a Function-driven discount instead of a hardcoded rate.
- Custom carrier service (rates engine): Your own endpoint returns blended, dimensional, or contract-priced rates in real time via the carrier service API. Full ownership of the rate math, and of the uptime.
- Effort band
- Functions lane: an estimated $8,000–$20,000; custom carrier-service engine: $25,000–$75,000 (Deploi estimates, illustrative). Most Functions work lands in the $10–25K contact-form band.
- Typical timeline
- 2–4 weeks for the delivery-customization Function; 6–10 weeks for a carrier-service rates engine (Deploi estimates, illustrative)
- Maintenance, honestly
- ~15–20% of build cost per year (Deploi estimate): Function API version bumps on Shopify's roughly six-month cycle, rule tweaks as carriers and thresholds move, and, on the carrier-service lane, production infrastructure with checkout-facing uptime you now own. There is no subscription line.
- What you own — and what you take on
- You own: the rule logic, the rate math, the metafield config surface, and the quote-log margin data. You take on: code-deploy rule changes unless you budget a small config UI, and live infrastructure at the store's most conversion-critical step if you go the carrier-service route.
3-Year Total Cost of Capability
| Buy (app path) | Build (custom path) | |
|---|---|---|
| Year 0 (setup) | $0–$1,000 (setup/config) | $8,000–$20,000 |
| Years 1–3 (recurring) | $3,600–$14,400 | $3,600–$12,000 (maintenance) |
| 3-year total | ≈$3,600–$15,400 | ≈$11,600–$32,000 |
- † All figures illustrative samples for the reference scenario — not quotes, not verified pricing.
- † App path: mid-tier rules-app pricing held flat; rating platforms tier up with order volume, which is conservative for the build case.
- † Build path scoped to the delivery-customization Function lane; a custom carrier-service engine roughly triples the upfront band. Three-year horizon.
What the Sticker Price Hides
On the buy path
- — Order-volume tiers scale with growth: cheap at install, expensive at success (community-reported pattern)
- — Live-rate calls are a checkout-blocking network hop; a provider hiccup shows shoppers no shipping options unless fallback rates are configured
- — Rule trees live in the vendor's UI and rarely export, so switching apps means rebuilding and re-testing every rule by hand
- — Live-rate apps need carrier-calculated shipping active on your Shopify plan; verify availability before the trial starts
On the build path
- — A delivery-customization Function hides, renames, and reorders; it can't create rates or reprice them, so scope the lane before you scope the build
- — Functions can't call external services at runtime, so every input the logic needs must already live in the cart, customer, or metafield config
- — Rule changes are code deploys unless you add a small config UI; skip it and ops queues a ticket for every threshold tweak
- — ~15–20% of build cost per year in upkeep (Deploi estimate), including Function API version bumps on Shopify's roughly six-month cycle
What Merchants Say
Scripts-deadline anxiety ran hot through the first half of 2026: teams with years-old shipping scripts hunting for where the hide-and-rename logic goes now that the June 30 shutoff has passed.
The recurring complaint shape for rate apps: live quotes time out or misprice an edge case, and the merchant learns about it from an abandoned-checkout report rather than an alert.
If You Change Your Mind Later
If you bought and outgrow it
Document every rule outside the vendor UI from day one, because rule trees rarely export in a portable format and the exit cost is a manual rebuild plus regression-testing rates across zones. Time the switch to a quiet season and run old and new rates in parallel on test orders before cutover.
If you built and want out
Function code is yours and small; if you ever retreat to an app, the rules translate as written requirements rather than stranded data. A custom carrier-service endpoint is the heavier exit, since it's live infrastructure: plan a fallback-rate window during any handoff so checkout never shows an empty shipping step.
When This Answer Changes
We're watching for:
- ▸ Shopify expanding native conditional rates (postal-code granularity, combined weight-and-price conditions) would widen the WAIT band
- ▸ Delivery-customization Functions gaining rate creation or repricing would widen the BUILD band (no sign as of July 2026 research)
- ▸ Legacy non-Plus checkout scripts removal lands 2026-08-26, closing the last Scripts-era surface weeks after this page's as-of date
Verdict change log:
- 2026-06-01Plus stores that ran rate logic in Ruby scripts for years now rebuild it as Functions. The lane is narrower than Scripts was (no rate creation or repricing inside a delivery customization), but it executes in-checkout with no network hop, and it's the sanctioned surface.
Common Questions
What replaced Shopify shipping scripts after the 2026 shutdown?
Shopify Functions: the delivery-customization API hides, reorders, and renames delivery options, and a shipping-discount Function covers logic that changes the price. Scripts stopped executing on 2026-06-30, so hide-or-rename logic still living in a script is already dark. The rebuild is bounded: an estimated 2–4 weeks for a typical rule set (Deploi estimate, illustrative), with config in metafields so thresholds stay editable.
Can Shopify's native settings handle conditional shipping rates?
Yes, for single-origin, threshold-simple offers. Native shipping profiles give you zone-based rates with weight or price conditions, free-shipping thresholds, and separate profiles per product group. They stop at dimensional weight, multi-origin blending, mixed conditions, and postal-code-level granularity. If your offer fits weight-or-price thresholds by zone, wait: spend nothing until the offer outgrows the settings, and put the budget where it moves margin.
When does a shipping rules app beat building on Functions?
When rates must be created rather than shaped. Live carrier quotes, dimensional box-packing, multi-origin blending, and freight are years of plumbing the rating platforms have already built, and a Function can only shape rates that exist. Buy that layer when you need it, keep the logic on top as your own Function, and reserve a full custom carrier service for when rate accuracy moves real margin at scale.
Your Next Steps
If you're going with BUILD
- Inventory every live shipping rule with its source (native, script-era, app), condition, and owner; the dead-Scripts list is your Function spec
- Confirm the lane: route any rule that creates rates (live quotes, dimensional) to native settings or an app first
- Model the logic as metafield config so thresholds change without a deploy
- Build and test the delivery-customization Function on a development store, covering PO-box, remote-zone, and oversized-cart edge cases
- Watch shipping-step abandonment for two weeks after cutover; rate bugs surface as silent abandonment, not error messages
If you're going with BUY
- Shortlist on your actual complexity (dimensional packing, multi-origin, carrier mix), not feature-list length
- Verify carrier-calculated shipping is active on your Shopify plan before the trial starts
- Configure fallback rates so a timed-out quote never leaves checkout without options
- Measure rate response times from your top shipping zones; latency at the shipping step is a conversion tax
- Document every rule outside the vendor UI from day one; it's your exit insurance
Official Docs & Sources
- About delivery and shipping functions — shopify.dev
- Third-party carrier-calculated shipping — Shopify Help Center
Official documentation linked for verification — our verdicts and estimates are our own.
Related Decisions
Advanced Shipping Rules vs. ShipperHQ: Which Weight Class?
Advanced Shipping Rules wins per-vendor and product-group rate math; ShipperHQ wins when dimensional, freight, or multi-carrier scope arrives.
Advanced Shipping Rules vs. Native Rates: App or Included Logic?
Native profiles plus a small delivery Function cover most mid-market rate logic; Advanced Shipping Rules earns its fee when blended rate math outgrows profiles.
ShipperHQ vs. Native Shopify Shipping: Do You Need the App?
Native rate settings plus one Delivery Customization Function beat ShipperHQ for single-origin, parcel-dominant Shopify stores.
Should You Build or Buy Checkout Customization on Shopify Plus?
Checkout customization on Shopify Plus is a build: own the Functions and extensions, rent only the generic blocks.
Should You Build or Buy Checkout Tracking & Pixels on Shopify?
Customize wins for checkout tracking on Shopify: an Elevar-class app for destinations plus an owned audit and server-side glue layer.
Ready to untangle your shipping rate logic?
We'll map your rules to the right lane (native settings, a Functions build, or a rating platform) and build only the layer that's genuinely yours to own. Scripts are gone; your logic doesn't have to be.
Contact us todayVerdict scored for the reference scenario above. Estimates are not quotes; app pricing carries its verification date and gets re-verified quarterly. Full scoring anchors: see the TCC methodology.
Read how we score these decisions (the TCC Framework). No affiliate links, no paid placement — no app vendor pays to appear here.