Shopify private vs public apps: which to build

The terminology has shifted over the years — "private apps" became "custom apps", and legacy private apps were retired in favour of custom apps and admin API access tokens. What hasn't changed is the underlying choice: are you building for one merchant or for the market?

The code can be identical. The project is not.

Custom apps

Built for a specific store, installed directly by link, not listed publicly, not reviewed by Shopify.

What this gets you:

• No review queue. Ship when it's ready.
• No listing, no screenshots, no marketing copy, no support inbox from strangers.
• Scopes and behaviour tailored to one merchant's actual situation — the build sequence is the same either way.
• Billing handled however you already bill that client — no revenue share.
• You can be as opinionated as the client needs.

What it costs you:

• One customer funds the whole build.
• Distribution is manual if the merchant runs several stores.
• Maintenance is on you or on them, forever.

This is what most bespoke Shopify work is, and it's what I'd default to for anything driven by a specific business need — an ERP integration, a pricing rule, an internal tool.

Public apps

Listed on the App Store, installable by any merchant, reviewed by Shopify against their requirements.

What this gets you:

• Distribution. The App Store is a real acquisition channel.
• Recurring revenue from many merchants through the Billing API.
• An asset with enterprise value rather than a project.

What it costs you:

• Review. Performance, security, privacy, mandatory webhooks, listing accuracy — see listing requirements. First submissions are commonly rejected.
• Support. Merchants email you. Some of them at weekends.
• Compatibility with every theme and every configuration, not one. This is the cost people most underestimate.
• Revenue share on App Store billing.
• Permanent maintenance as Shopify's API versions rotate.

A public app is a software product. Treat it as a business, not a side effect of a client project.

Choosing

If you're building it because a client asked and paid, build custom. If you're building it because you believe many merchants have this problem, build public — and accept that you're starting a company, not finishing a feature.

The middle ground

Two patterns worth knowing:

Custom app, multiple stores. A merchant with several storefronts can install the same custom app on each. Fine, and common. It's still not a public app — no review, no listing.

Build custom first, generalise later. Solve one merchant's problem properly, learn where the real complexity is, then decide whether it generalises. Most of the value in a public app is knowing which 20% of the feature set matters, and one paying client teaches you that faster than speculation does.

The trap is the reverse: building for the market on a client's budget. The client pays for generality they don't need, the timeline doubles, and the result serves neither.

Cost

A custom app is a project with a defined end. A public app has ongoing costs from day one — hosting, support, compatibility work, review cycles. App development cost breaks both down.

The question isn't technical. It's whether you're solving a problem or starting a product — and the answer changes the budget by an order of magnitude.