Building a Shopify app: the decisions before the code

Roughly speaking, an app is what you build when the behaviour you want cannot be configured, cannot be modelled as data, and cannot be bought. Before scoping one, rule out the three cheaper answers in that order, because each is an order of magnitude less work than the thing underneath it and none of them leaves you owning a codebase.

Is it a workflow? “When an order comes in over £500, tag it, notify the warehouse and hold it for review” is a Shopify Flow, not an app. Flow handles triggers, conditions and actions across orders, customers, products and inventory, and a merchandiser can change it on a Tuesday without a deployment. Teams reach past Flow because it feels less serious than a build. It is less serious. That is the point.

Is it data? “Each product needs a care guide, a fabric composition and a set of certifications” is metafields, or metaobjects if the same structured thing is reused across products. A custom app that stores product attributes in its own database has invented a second source of truth about your catalogue, and now every other system has to be told which one wins.

Is it already installed? A surprising number of app briefs describe something an app the merchant already pays for does, behind a setting nobody turned on. Audit first. The cheapest app is the one whose subscription is already leaving your account.

What survives that filter is the real category: an integration with a system Shopify has no connector for, a business rule nobody else has, a tool your staff use daily that does not fit in the admin as it ships. Those are worth building. The rest are worth not building.

Shopify documents two distribution routes, and the difference between them decides most of your budget.

Public distribution means the app is listed on the Shopify App Store and can be installed on any store. It goes through Shopify’s app review. Apps published on the App Store are required to use a Shopify-provided billing solution, and Shopify App Pricing is what new public apps are told to use. Shopify takes a share of what it collects and handles chargeback disputes.

Custom distribution means the app installs on a single store, on multiple stores within the same Shopify Plus organisation, or on transfer-disabled development stores. No app review. No listing. The documented trade is that a custom-distribution app cannot use Shopify’s billing system to charge merchants — which is irrelevant when the merchant paying for the app is the one who commissioned it.

The documentation is explicit that the distribution method cannot be changed once selected. That is the sentence to read twice. A merchant who builds their own tool as a public app in case they sell it one day has taken on app review, listing requirements and a billing integration for a business that does not exist yet. A partner who builds a product as a custom app because it was faster has to start again to list it.

Our default for a merchant building a tool for themselves is custom distribution, every time. If the commercial ambition to sell it to other merchants is real, that is a product decision with a product’s funding behind it, and it should be made deliberately at the start rather than hedged.

Shopify’s documentation lists the surfaces an app can occupy: App Home, which is your app’s own page in the admin; the admin itself; checkout; customer accounts; the online store; and point of sale. Each surface, as the docs put it, “comes with its own extension types, APIs, and design rules”.

This matters more than it sounds, because a surface is a constraint as much as a location. Checkout is the sharp example — what is allowed there is narrow and deliberately so, and an idea that assumes free rein over the checkout page will not survive contact with the extension API. Working out the surface early turns a vague brief into a testable one.

It also decides who your user is. An app that lives in App Home is a tool for staff. An app that ships a theme app extension is a change to what shoppers see, and it inherits the storefront’s performance budget along with it. The two need different skills, different QA and different definitions of done, and briefs that cover both are usually two projects.

Shopify’s split is stated plainly: extensions, Functions and custom data are hosted by Shopify; your app’s home page and backend are hosted by you.

That leaves an option worth knowing about. Extension-only apps are made up entirely of extensions, which means Shopify hosts them and there is no developer-hosted backend at all — extensions can even render the app’s main page in App Home. No server, no deployment pipeline, no database to back up, no certificate to renew at 2am. The documented limitation is that extension-only apps can only be installed with custom distribution, and that anything needing public distribution or more than the UI extension runtime must be self-hosted with the app configuration pointed at your own URL.

For a merchant’s internal tool, that constraint costs nothing and the saving is permanent. Hosting is not a one-off line on a build quote; it is a bill and a maintenance obligation for as long as the app exists. If your app can be extension-only, that is a genuinely different total cost from one that cannot.

The moment you need a backend is usually the moment you need to talk to something that is not Shopify, hold state Shopify does not model, or run work on a schedule. Those are good reasons. “We might need one later” is not.

App budgets tend to be drawn around the feature and then surprised by everything around it. The obligations below are documented requirements, not polish, and they apply whether or not anyone remembered to scope them.

Compliance webhooks. Shopify’s documentation states that any app distributed through the App Store must respond to data subject requests regardless of whether the app collects personal data. There are three topics — customers/data_request, customers/redact and shop/redact, the last sent 48 hours after uninstall — and the requirements are to acknowledge with a 200-series status, verify the HMAC header and return 401 if it is invalid, and complete the action within 30 days. There is a documented exception where you are legally required to retain data.

Performance, if you touch the storefront. The App Store requirements state that an app should not reduce Lighthouse performance scores by more than 10 points, tested as a weighted average across home, product detail and collection pages. That is a pass/fail gate on a number most app briefs never mention.

API currency. Apps using APIs deprecated within the last 90 days cannot be submitted, and only documented APIs may be used for checkout customisation. An app is not a thing you finish; it is a thing that needs a maintenance budget because the platform underneath it moves.

The listing, if you are public. Complete listing information, clear setup instructions with a screencast, valid test credentials for any third-party integration, and a privacy policy. None of that is code and all of it is work.

We build custom Shopify apps and back ends, and the best outcome of a scoping call is quite often that we do not build one. An app is a permanent addition to the number of systems you own. A Flow is a setting. The gap between those two, in lifetime cost, is larger than the gap between any two quotes you will get for the app itself.

When an app is the answer, build it small and build it custom-distributed unless you have a commercial reason not to. Ship the one workflow that hurts most, watch somebody use it, and add the second thing only after the first has earned it. An app you can stop is an app you can afford to start.

• Custom Shopify apps and back ends
• Theme app extensions: apps that do not touch your code
• Shopify Flow: automation that replaces an app