Shopify extensions are one of the most misunderstood tools in modern commerce engineering. On a slide deck they look simple: drop a block on an order page, add a POS tile, validate checkout. In production they force you to confront a harder question, where does the business rule live, and what is allowed to execute in this surface?
I have spent years shipping Admin UI extensions, admin action links, checkout UI extensions, theme app extensions, POS UI extensions, and Shopify Functions. The lesson is consistent: the extension is rarely the product. It is a constrained window into a larger system.
The surface is not the system
An Admin block on admin.draft-order-details.block.render can present controls. A POS tile on pos.home.tile.render can start a modal. A checkout block on purchase.checkout.block.render can collect a tip or delivery preference. None of those targets give you a free-form backend.
That constraint is the point. Shopify deliberately limits what runs on Admin, Checkout, and POS so merchants stay safe and the platform stays stable. Your job is to design around those limits instead of fighting them.
A useful mental model:
- Presentation lives in the extension (UI, local validation, calling APIs you are allowed to call).
- Configuration often lives in the Remix/admin app (merchant settings, metafields, Prisma models).
- Hard rules that must be trustworthy belong in Functions, server-side APIs, or event workers, not in a UI that a browser can ignore.
If you put credit-limit enforcement only in a checkout UI component, a determined client can bypass it. If you put it in a purchase.validation Function, checkout cannot complete until the rule passes. That distinction is architecture, not preference.
Targets multiply complexity faster than features
Every extension declares targets. Each target is a different lifecycle, data shape, and permission model.
On one POS loyalty project we needed:
- a home tile and modal for starting the flow
- line-item actions for marks on a specific cart line
- post-purchase actions/blocks for after the sale
- an Admin link on product details for configuring points
That is not “one POS app.” That is four interaction contracts that must stay coherent with one domain model. Miss one surface and cashiers invent workarounds. Overbuild one surface and you create two sources of truth.
Checkout is similar. Delivery date UI, tip UI, address prefill, and date validators may all render in checkout, but they touch different cart attributes, metafields, and blocking capabilities (block_progress, network_access, api_access). Turning the wrong capability on expands your threat model. Leaving the wrong one off makes the feature feel broken.
Functions are where complexity becomes honest
Shopify Functions (discounts, cart transform, validation) run in a WASM sandbox with strict input queries and tiny execution budgets. That forces clarity:
- What input do I actually need?
- Can this rule be expressed without a network call?
- What happens when the Function fails closed vs fails open?
Cart transforms that adjust tip line prices, subscriber discounts that rewrite line discounts, and checkout validation that enforces credit limits all look “small.” They are not. They sit on the money path. A bug is not a visual glitch. It is incorrect totals, blocked checkouts, or silent policy holes.
The complexity is often in composing Functions with UI extensions. UI collects intent (tip amount, delivery choice). Function or server enforces consequence. If those two disagree, merchants stop trusting both.
Admin extensions change operating models
When staff can manage delivery from an order action link, or open signature/order tooling from Admin, you are redesigning operations, not just UI. That means:
- role assumptions (who can see the action?)
- deep links that survive Admin navigation changes
- app routes that degrade gracefully when session/auth is stale
- logging that ties Admin clicks to backend mutations
The hardest bugs are usually not “extension did not render.” They are “extension rendered, staff clicked, backend partially applied state, Admin still shows the old world.”
What I learned to design first
Before writing extension code, I now answer these in writing:
- Which Shopify surface is the source of truth for this action?
- What must be impossible even if the UI is compromised or skipped?
- Which data is cart attribute vs metafield vs app database?
- What is the failure UX when network/API access is denied?
- How do Admin, POS, and Checkout stay consistent if only one ships this sprint?
Extensions feel like frontend work. They are distributed systems with a friendly SDK. Treat them that way and the complexity becomes manageable. Treat them like widgets and you will rediscover the edge cases in production, usually on a Friday.