Shopify App Development

When a theme stops being able to say no

Every Shopify store eventually meets a requirement the theme cannot hold. Not a design requirement — a logic one. A B2B customer who should see net pricing and nobody else should. A bundle whose components have to leave stock individually. A delivery date that has to be validated against a courier cut-off before the order is allowed through. A subscription that has to reconcile with an ERP that was specified in 2011.

These are not theme problems, and no amount of Liquid will make them theme problems. Liquid renders; it does not decide. The moment a requirement needs something to be true at the point of order rather than at the point of display, the work moves out of the theme and into the app layer — and that is the layer this page is about.

The merchants who arrive here have usually already tried the alternatives, in the order everyone tries them. First an App Store subscription that does eighty per cent of it. Then a second app to cover the rest, which conflicts with the first. Then a piece of theme code from a freelancer that works until the next theme update. By the time someone writes to us there are typically four apps loading on a product page, two of them doing overlapping jobs, and nobody in the business is certain which one owns the price the customer actually sees.

Custom app or public app

This is the single distinction worth getting right before anything else, because it changes the cost, the timeline and the risk profile of everything downstream.

A custom app is built for one store. It installs with a direct link, is never listed on the App Store, and is never reviewed by Shopify. It can use the same APIs, the same extension points and the same Functions as anything on the App Store. It ships in a fraction of the time because there is no listing, no review cycle, no billing integration, and no obligation to be comprehensible to a merchant who has never spoken to you.

A public app is a product. It installs via OAuth for any merchant, needs billing, needs to pass Shopify’s App Store review, and needs to keep working for people you will never meet. Building one is a reasonable commercial decision if distribution is the point — if the app is the business, or if it is a channel into an audience you want. It is an expensive way to solve a problem for one store.

Most of the briefs we are sent describe a custom app and ask for a public one, usually because “app” and “App Store” have become the same word. Establishing which one you actually need is the first thing the scope call does, and it routinely takes a third off the estimate.

Where the extension points are

Shopify’s customisation surface is wider than it was and considerably more structured. The parts that matter:

Checkout UI extensions are how checkout is customised now. Shopify retired checkout.liquid for the checkout steps in August 2024 and for the Thank you and Order status pages in August 2025. Extensions on the checkout steps themselves require Shopify Plus; the Thank you and Order status pages are open to merchants on other plans. If your store still runs checkout.liquid customisations, they are on a surface Shopify no longer supports, and moving them is app work.

Shopify Functions replaced Shopify Scripts on the same 2025 date. They run discount logic, shipping and payment method customisation, cart transforms and cart and checkout validation — written in Rust or JavaScript, compiled to WebAssembly, executed by Shopify rather than by a server you rent. That is what makes them viable inside a price calculation: there is no network hop, so there is no latency to add. It also means real constraints on execution time and input size, which is why the technical design step exists before anyone writes code.

Admin UI extensions put your team’s tools inside the Shopify admin, where they already work, rather than in a separate dashboard nobody remembers to open.

Theme app blocks are how an app reaches the storefront without a script tag on every page. A merchandiser places the block, on the template that needs it, in the theme editor. Nothing loads anywhere else.

Flow covers the automations that need no code at all, and a serious share of what gets briefed as app work is a Flow that nobody had written yet.

How we build

The design step is written down and approved before application code is written. It names the extension points, the API scopes, the data model and the Shopify limits that will shape the build — because on this platform the limits are the design. An app that assumed synchronous inventory when the API is eventually consistent does not get fixed later; it gets rewritten.

Scopes are requested minimally and inventoried in writing. If an app asks for write_customers, the document says which feature needs it. This matters more than it sounds: scopes are the part of an app a security review will ask about, and an app that asked for everything on day one cannot answer.

You get an install link in the first week. Not a demo, not a screen recording — the thing itself, in a development store, incomplete. It is the only reliable way to discover that the requirement everyone agreed on in the scope call is not quite the requirement the business has.

After launch, which is when apps actually get expensive

Shopify ships API versions quarterly and supports each one for a year. An app is not a delivered artefact; it is a standing commitment against a platform that moves. Extensions get deprecated. Scopes get split. Behaviours that were undefined become defined, and code that depended on the undefined behaviour stops working on a Tuesday.

We track the release notes that touch your app specifically and tell you before something breaks, not after. That is the part of this service that is worth paying for over a five-year horizon, and it is the part nobody puts in a proposal.

And the app is yours throughout. It lives in your Partner organisation. The source lives in your repository from the first commit. If you decide to take it in-house or hand it to someone else, there is nothing to extract and no conversation to have — which is the only honest test of whether a development partner was ever holding you hostage.