When a custom app becomes a product

Most teams arrive at this question assuming the path is gradual: build it for ourselves, prove it, flip a switch, list it. That path does not exist. Shopify's distribution documentation states plainly that "You can't change the distribution method after you select it", and the two methods differ in ways that matter from day one.

A custom-distribution app is "Installed on a single Shopify store, on multiple stores that belong to the same Plus organization, or on transfer-disabled development stores". It needs no approval from Shopify. And it "Can't charge merchants through Shopify's app billing system". A public app can be installed on multiple stores, requires approval, and is required to "Use Shopify App Pricing to charge for your app", billing merchants "through the same system that's used for their Shopify subscription".

So publishing is not a migration. It is a new app, with its own listing, its own review, its own installs, and no route to carry your existing merchant across other than uninstalling one and installing the other. Whatever you decide, decide it knowing the original app is not an asset you are upgrading — it is a prototype you are keeping.

The App Store is not a directory you submit to; it is a set of obligations you accept indefinitely. Several are worth reading before anyone writes a business case.

Compliance webhooks, whether or not you hold data. Shopify requires every app distributed through the App Store to subscribe to customers/data_request, customers/redact and shop/redact, and states that such an app "must respond to data subject requests, regardless of whether the app collects personal data". The action must be completed "within 30 days of receiving the request". That is an operational process with a legal clock on it, not an endpoint you stub out.

A performance ceiling you must hold. The requirements state that an app "shouldn't reduce Lighthouse performance scores by more than 10 points". For anything touching the storefront this is a real constraint, and it is checked.

A prescribed authentication and embedding model. App Bridge for OAuth redirects, session tokens rather than "third-party cookies or local storage", OAuth performed immediately on install "even if the merchant has previously installed and then uninstalled your app", and only the access scopes you genuinely need. Storefront changes go through theme app extensions rather than manual code edits.

A moving API floor. Apps "using APIs that will be deprecated within 90 days can't be submitted". Read that as a permanent maintenance commitment: the platform moves, and staying listed means moving with it on Shopify's schedule rather than yours.

Billing through Shopify. You must use Shopify App Pricing, which means the merchant relationship, the billing cycle and the dunning are partly Shopify's. Shopify also takes a share of App Store revenue; we are deliberately not quoting a figure, because the terms have been revised more than once and the number in a blog post is the wrong place to learn it. Check the current terms in your Partner dashboard and model them before, not after.

Ask someone modelling an app business what it costs to run, and they will describe engineering. The dominant cost is support, and it behaves differently: it scales with the number of merchants, not with the amount of code, and it does not go down when development stops.

The requirements themselves gesture at this — you are expected to provide "clear, Shopify-specific instructions in your help documentation and in-app context so merchants can quickly resolve issues themselves" — but self-service documentation reduces tickets, it does not eliminate them. A hundred merchants on a £19 plan is a support queue, a status page, a changelog, a refund policy and somebody answering on a Friday afternoon. That is a team, funded by revenue that arrives in £19 increments and churns.

This is the honest reason most custom apps should stay custom. The code was the cheap part and it is already done. What publishing buys you is an obligation to a long tail of small merchants whose expectations are set by apps with venture funding and a support department, in exchange for a revenue line that will take years to matter and may never cover the distraction from the business that is actually paying you.

Between "keep it to ourselves" and "launch a software company" are two options that get skipped.

Custom distribution across an organisation. If the driver is that you run several stores, you may not need the App Store at all — custom distribution covers "multiple stores that belong to the same Plus organization". That is a configuration decision, not a product launch.

Build it again, deliberately, for the second merchant. If one other business wants what you built, a second custom app for them is a straightforward engagement with a known scope, billed directly, with no App Store review, no compliance webhook obligations and no revenue share. Do that twice more and you will have learned what the product actually needs to be — and you will have been paid to learn it, which is a considerably better position than launching and finding out.

And settle the ownership question first. If an agency built the app for you, or you built it for a client, who owns the code is a contract matter that people discover at the exact moment the idea gets exciting. It is a five-minute conversation before, and a bad one after.

We build custom Shopify apps and we will tell most clients not to publish them. Not because the work is beneath doing, but because the thing that makes a custom app valuable — that it fits one business exactly, with no settings, no compromises and no support burden — is precisely what has to be removed to make it a product.

If you want a product, the sensible sequence is to treat the custom app as market research rather than as version one. Find out whether anyone else will pay before you rebuild it for them. And if the answer is yes, start the public app as a new app on purpose, with the distribution decision made deliberately on day one, because Shopify will not let you make it twice.

• Custom Shopify apps and back ends
• Building a Shopify app: the decisions before the code
• Theme app extensions: apps that do not touch your code