--- title: "Custom Shopify App or Public App: How to Choose" description: "A custom app assumes one merchant, one theme, one configuration. A public app can assume none of those, and that difference runs through the whole build." author: "Aashish Kaushik" published: 2026-09-07T13:00:31.133Z updated: 2026-09-07T13:00:31.137Z url: https://blog.byteinfy.com/custom-vs-public-shopify-app --- # Custom Shopify App or Public App: How to Choose ## Key takeaways - The decision precedes any code and determines review obligations, billing, support burden and how much you may assume. - A custom app can assume one theme and one configuration; a public app must work on stores you will never see. - Retrofitting a custom app into a public one usually means rewriting the assumptions, because the assumptions are load-bearing. - Build custom when you have a client, public when you have a market — and be honest about which you actually have. The public-versus-custom decision gets made casually and then constrains everything afterwards. It is worth about an hour of deliberate thought, because it is expensive to reverse. The core difference is not distribution. It is **how much you are allowed to assume**. > **The one-sentence test** > > Build custom when you have a client. Build public when you have a market. Confusing the two is where the expensive mistakes start. ## What each one actually is **A public app** is listed on the App Store and installable by anyone. You get discovery — merchants find you without you finding them — and in exchange you accept Shopify's review, the requirements checklist, a support obligation to strangers, and a product that must work on themes and configurations you will never see. **A custom app** is built for one merchant. No listing, no review, no unknown themes. You can assume their theme, their catalogue shape, their business rules. You also get no distribution, and if that client leaves, the app has no other market. ## The practical differences | Public app | Custom app | | --- | --- | | Distribution | App Store discovery | None | | Review process | Required | Not required | | Requirements checklist | Applies fully | Largely not | | Themes to support | All of them | One | | Support burden | Unknown merchants, at scale | One known client | | Billing | Shopify billing API, revenue share | Whatever you agree | | Cost to build | Higher | Lower | | Ongoing cost | Support, review, compatibility | Maintenance for one client | ## Assumptions are the whole difference This is the part that determines cost, and it is worth being concrete. A custom app can assume the merchant's theme structure, so storefront rendering is straightforward. It can assume their product data is shaped a particular way. It can assume a specific set of other apps is installed. It can assume the merchant knows how to use it, because you will show them. A public app can assume none of that. Every theme is different. Product data varies wildly in completeness. Other apps you have never heard of will touch the same cart. And onboarding has to work for a merchant with no context, on an empty store, without you present. That is why a public app costs more to build for the same visible functionality. Most of the extra work is invisible in a feature list. ## The retrofit trap The most common expensive mistake in this decision. A team builds a custom app for a client, it works well, and someone suggests listing it. The reasoning seems sound — the hard part is done, it just needs a listing. It rarely works out that way, because the assumptions are load-bearing. One theme becomes every theme. One configuration becomes every configuration. One client who can be phoned becomes a support queue of strangers. Onboarding designed for a handover meeting has to work unattended on an empty store. The realistic answer is usually a substantial rewrite of everything except the core logic. That does not mean never do it. It means decide honestly at the start: if listing is a genuine intention, build public from day one and accept the higher cost. If it is a vague possibility, build custom and treat any future listing as a new project with its own budget. ## Choose custom when **You have a specific client with a specific need.** The clearest case, and the most common. **The requirement is genuinely unique to their business.** Nobody else would install it, so distribution is worth nothing. **It integrates with systems only they have.** An ERP, a warehouse system, a bespoke internal tool. **Speed matters more than reach.** A custom app can ship considerably faster, because it skips review entirely and can assume its own environment. ## Choose public when **You have identified a real market**, not a hypothetical one. Ideally several merchants have asked for the same thing. **The function generalises.** If solving it for one merchant solves it for a hundred, distribution is worth having. **You can sustain support.** This is the condition most often underestimated. A public app generates tickets indefinitely, and most are not bugs — they are themes behaving unexpectedly, other apps conflicting, and merchants configuring things in ways you did not imagine. **You want recurring revenue** rather than project fees, and you are prepared for the ongoing obligation that comes with it. ## Before committing either way - Name who will install this — a client, or a market you can describe - Decide whether listing is a genuine intention or a vague possibility - Establish who handles support in a year, and whether they can - Confirm your billing model matches the choice - Check whether the requirement generalises or is genuinely specific - Budget for review and compatibility if public, maintenance if custom ## The middle options people forget The choice is presented as binary and there are two other arrangements worth knowing, both of which suit situations where neither pure option fits. **An unlisted public app.** Built as a public app, subject to the same architecture, but not surfaced in App Store search. Installed by direct link. This suits a small set of known merchants — a group of clients, a franchise network, several stores under one ownership — where you want the discipline and multi-store capability of a public app without a listing. **A public app with a private tier.** A listed app that also serves specific clients with configuration or features they paid for. Common among agencies who built something for one client, found it generalised, and now run both models from one codebase. Both add complexity, and neither should be chosen first. But if you find yourself saying "it is custom, but for four merchants", one of them is probably what you actually need — and building four custom apps, or one custom app with hardcoded branches for four clients, is the outcome to avoid. ## Ownership and what happens afterwards A commercial question that developers under-discuss and clients care about a great deal. **Who owns the code?** For custom work this needs settling in writing before the build. A client paying for a bespoke app usually assumes they own it; agencies often assume they retain reusable components. Both positions are reasonable and they need reconciling in advance rather than at the point of separation. **Who maintains it?** Shopify ships continuously and retires API versions on a published schedule. An app that is built and never touched will eventually break, on someone else's timetable. Somebody has to own that, and "the agency, presumably" is not an arrangement. **What happens if the relationship ends?** A custom app with no documentation, built by an agency the client no longer works with, is one of the more expensive positions a merchant can be in. Documentation and a clean handover path are worth agreeing at the start, when nobody is annoyed. **For public apps, what happens if it stops paying?** Apps get abandoned, and merchants who built workflows around them are left stranded. If you are building public, having an honest position on what you would do — sunset gracefully, open-source it, sell it — is worth more than pretending the question will not arise. > **Decide the maintenance arrangement before you build** > > The most common failure in custom app work is not technical. It is an app that works perfectly for eighteen months, breaks when an API version is retired, and belongs to nobody. Name who watches for deprecations and who pays for the upgrade, in the same conversation where you agree the build. ## What custom apps should borrow from the checklist A closing point worth making, because it is easy to lose. Custom apps skip App Store review, which removes real work. It also removes a discipline that was doing something useful. Several requirements on that checklist are good practice regardless of who installs the app: handling reinstalls and scope changes properly, implementing compliance webhooks, using theme app extensions rather than injecting code into themes, and not leaving debris behind on uninstall. A custom app that ignores all of it is cheaper to build and worse to live with — particularly for the client, who inherits theme injection and an app that cannot be cleanly removed. Read the checklist even when it does not apply to you, and adopt the parts that are about quality rather than about listing. The same applies in reverse to the parts that genuinely do not matter for a single merchant. A custom app does not need a polished onboarding flow for someone with no context, because you will be in the room. It does not need to handle every theme. Skipping those is not cutting corners; it is the whole reason custom is cheaper. The discipline is distinguishing between requirements that exist because the App Store demands them and requirements that exist because the software should be good. For the wider build considerations, see [Shopify development](/category/shopify-development). The review process specifically is covered in the same archive, and the app-versus-custom-work question from a merchant's side in [Shopify apps](/category/shopify-apps). **Building an app and unsure which shape it should be?** ByteInfy designs and builds both — custom apps for single merchants and public apps through App Store review — and will say plainly which your situation warrants. [Start a project](https://byteinfy.com/#contact) ## FAQ ### What is the difference between a custom and a public Shopify app? A public app is listed on the Shopify App Store, installable by any merchant, and subject to Shopify's review and requirements. ### Do custom Shopify apps need to pass App Store review? No. App Store review applies to public listings. ### Can I turn a custom app into a public one later? You can, but it is usually more work than expected. A custom app is built assuming one theme, one configuration and one set of business rules. ### Which is cheaper to build? Custom, usually by a considerable margin, because it can assume things a public app cannot. ### How do custom apps handle billing? However you agree with the client, typically outside Shopify's billing API — an invoice, a retainer, a project fee. Public apps generally use Shopify's billing with its revenue share.