One merchant’s problem is a feature; ten merchants’ problem is a product. The custom-app-versus-public-app decision looks like a technical choice — where the code lives, which API scopes, who pays the hosting — but it’s actually a product decision about who the software serves, how it’s sold, and what you’re committing to maintain.
Get it wrong in the custom direction and you’ve built a product nobody outside one client will ever use, maintained at product cost. Get it wrong in the public direction and you’ve signed up for support, distribution, and upgrade obligations that a “quick app for a client” never asked for. This post is the framework for telling the two apart before you write the first line.
The question underneath the question
When a client asks for an app, the real question is: is this a one-off workflow, or a repeatable capability? The answer determines everything downstream — not just the code, but the business model.
Ask the client three follow-ups:
- “Does the problem exist outside this store?” If the workflow is specific to their operations — their warehouse, their approval chain, their bespoke pricing — it’s a feature. If another merchant in the same vertical would hit the same workflow next week, it’s a product.
- “Would you pay for this again, as a subscription, with someone else maintaining it?” The client’s answer tells you whether the economics are sustainable. A one-time build with free maintenance is a feature; recurring willingness to pay is the seed of a product.
- “Who is going to support this in two years?” If the honest answer is “you, at your cost,” it’s a feature. Products need support budgets, SLAs, and a roadmap — or they need to be honest features with a maintenance retainer.
The same underlying engineering can go either way. The difference is the commitment.
A framework for deciding
Score the project against five axes. Three or more on the “product” side, and you should be thinking about a public app (or at least a productized private app sold as a service).
- Repeatability. Do the requirements generalize, or are they store-specific hardcoding? Product: the same settings model works across stores with configuration. Feature: the code has the client’s name in it.
- Distribution. Can this reach other merchants without you selling it store by store? A public app gets Shopify’s App Store distribution, review, and listing. A custom app lives on exactly one store.
- Maintenance surface. Public apps face Shopify’s API versioning on a schedule, and merchants expect compatibility through upgrades. Custom apps are maintained on your schedule — but the maintenance still exists; it’s just invisible and unbudgeted.
- Data and scope needs. Custom apps can request the scopes they need and live quietly on one store. Public apps go through app review with stricter expectations about data usage, permission scopes, and privacy.
- Business model. Subscription revenue, app store fees, support costs. A public app is a business: marketing, onboarding, churn. A custom app is a deliverable: build, hand over, invoice.
The trap is the middle: a “custom” app built so well it could be a product — shared components, generic settings — but still sold as a one-off. You’ve then absorbed product costs (generalization, testing across configurations) with feature revenue (one build). That’s the worst of both worlds. If you’re generalizing anyway, productize the pricing; if you’re pricing as a feature, stop generalizing.
The code is the same; the contract is not
Technically, both start with the same machinery: an embedded app served over HTTPS, OAuth via the Admin API, scopes, webhooks, and a UI in the Shopify admin. The differences are contractual, not architectural:
- Embedding and distribution. Custom apps are installed per store via the app setup URL; public apps are distributed through the App Store with listing review. Unlisted public apps offer a middle path — distribution by URL without a listing.
- API versioning. Public apps are pinned to a Shopify API version and must upgrade on Shopify’s schedule (versions are supported for a year, then deprecated). Custom apps also use versioned APIs, but you control when you upgrade — and the risk of “it worked last year” lives on your timeline.
- App review. Public apps go through Shopify’s app review; custom apps don’t. Review is a forcing function for documentation, privacy, and data-handling hygiene — costs that are easy to skip on a custom app and that you’ll regret during a merchant audit.
- Partner Dashboard and ownership. Both live under a Partner account, but public apps carry listing ownership, distribution analytics, and app-store obligations that change who you’re accountable to.
Decision rule of thumb: if you can’t name a second buyer, it’s a feature — build it custom and price it accordingly. If you can name five, it’s a product — build it public, and budget support and distribution as first-class costs. If you’re between one and five, you’re choosing a business model, not a codebase — and the choice should be explicit, not accidental.
When the answer changes
The decision isn’t permanent. A custom app that keeps getting requested by new clients is a product in disguise — the moment three merchants ask for the same workflow, the economics flip, and a public app (or a productized offering) becomes the sane path. Conversely, a public app that nobody beyond your first client uses is a feature wearing a product’s costs; winding it down and turning it into a maintained custom app — or a maintenance retainer — is often the honest move.
When to call in help
If you’re deciding between a custom build and a public app — or you’ve built something in the middle and can’t tell which side of the line it’s on — a scoped architecture and product review can map the requirements, the distribution options, and the maintenance economics, and give you a recommendation with the numbers behind it. The wrong call is expensive in either direction; the review is cheap insurance before you commit the build. Book a Commerce Architecture Review and bring the three client questions.