A mid-sized ecommerce store has specific requirements Shopify core doesn't meet: CRM integration for customer sync, advanced analytics on customer behavior, data security and support requirements the merchant won't compromise on. The solution is an app. The question is which kind.
Shopify's app model has three distinct paths, each fitting different scenarios. Architects picking the wrong one over-engineer or under-engineer.
Three kinds of Shopify apps
Custom app. Built and installed for one specific merchant. Not listed on the App Store, not reviewable by Microsoft. Installed directly by the merchant via admin (or via Shopify Partners creating a custom app for that shop). Ships bespoke functionality, lives as long as the merchant needs it.
Public app (unlisted). Built by a developer, not on the App Store but distributable via a direct link. Multiple merchants can install. No Shopify review required. Good for small-scale ISV distribution or niche tools.
Shopify App Store public app. Listed on apps.shopify.com. Subject to Shopify's review and compliance requirements. Access to a broad merchant audience. Comes with recurring-billing subscription model through Shopify Billing API.
When custom fits
For the mid-sized merchant above - specific CRM integration, advanced analytics unique to their business - custom app is typically the answer. Why:
- Fast time-to-value: no App Store review cycle (which takes weeks). Ship updates same day.
- Bespoke integration: the app talks to this merchant's CRM, not a generic one
- Data security: the merchant controls where the app is hosted, who maintains it, what logs are kept
- Full support relationship: the app maker is engaged directly with the merchant; no "file a ticket with app developer" workflow
Custom apps are authored via Shopify CLI with app type "custom" and installed via a direct install link or admin. Shopify Functions, theme app extensions, admin UI extensions - all work the same as public apps.
When public (unlisted) fits
A developer ships a utility to 5-20 friendly merchants. Don't want the App Store review overhead. Don't need to reach every Shopify merchant.
Examples:
- Agency productized tool used by their own client roster
- Niche vertical tool shared across a tight community
- Pre-launch version of a future App Store app
The merchants install via direct link (e.g., https://admin.shopify.com/store/{shop}/admin/oauth/install?client_id=...). The app authenticates via standard OAuth; functionality is identical to App Store apps.
When Shopify App Store fits
Product-thinking. The app solves a widespread problem, works for many merchants, has a recurring-revenue model.
- App Store listing brings SEO and discoverability
- Subscription billing handled through Shopify Billing API with automatic renewals
- Shopify review ensures baseline quality (and gates entry)
- Large addressable market
The review cycle takes 2-8 weeks per submission. Strict validation rules: GDPR data-request and customer-redact webhooks required, app-listing rules, pricing display rules. Worth it if the app has genuine product-market fit; overkill for one-off bespoke work.
The decision framework
Questions that separate the three paths:
- Is the app for one merchant or many?One → custom appFew friendly merchants → public unlistedMany, public market → App Store
- Is Shopify review friction acceptable?No (need to ship fast) → custom or unlistedYes (product thinking, distribution matters more than speed) → App Store
- Does the functionality depend on merchant-specific data or generic patterns?Merchant-specific (their CRM, their warehouse) → customGeneric (everyone who sells X needs Y) → App Store
- Is recurring revenue via Shopify Billing needed?Yes → App Store (Billing API fits App Store apps)No → custom (bill independently)
Technical setup is similar
Regardless of distribution path, the app itself is the same architecture:
- Built with Shopify CLI
- Authentication via OAuth
- Admin UI via Polaris + App Bridge
- Theme integration via theme app extensions
- Checkout integration via checkout UI extensions
- Business logic in Shopify Functions where latency-sensitive
Custom, unlisted, and App Store apps share the same CLI commands, the same API access, the same extension types. The difference is distribution and billing.
Migration between paths
Apps can migrate:
- Custom → App Store: productize the app, add configuration options for variability, go through App Store review
- App Store → custom: not a common path; usually a new custom app built for specific merchant needs instead
The migration from custom → App Store is a classic ISV journey: build for one client, productize when the same need surfaces across multiple clients.
Billing and support considerations
Custom app billing: invoiced by the app maker directly (via their own system). Not through Shopify.
Public unlisted billing: same as custom - direct invoicing outside Shopify.
App Store billing: Shopify Billing API handles subscriptions, free trials, usage-based charges. Revenue share: merchant's subscription revenue goes to the app maker minus Shopify's commission.
Support model mirrors billing:
- Custom: direct relationship, SLA in contract
- Unlisted: direct relationship, often less formal
- App Store: public support channels, reviews, user ratings matter
What ships with each
Custom app ready for production:
- OAuth flow with merchant
- Admin pages via Polaris
- Required extensions (theme, checkout) as needed
- Billing through the app maker's system
- Support / maintenance agreement with the merchant
- Data security documentation
App Store app additionally needs:
- Privacy webhooks (shop/redact, customers/redact, customers/data_request)
- Billing implementation via Shopify Billing API
- App listing copy, screenshots, videos
- Review readiness (accessibility, error handling, documentation)
- Support channel (email, help center, etc.)
Picking the right path first saves the rework of productizing when the initial choice doesn't fit.