Custom Shopify app or public app? How to decide

Most stores we audit have one of two app problems. Either a stack of public apps is doing a job that one small custom tool could do cleanly. Or a custom build is quietly doing a job a well-supported public app now handles better.

So which should you choose? Use a public app when the job is common and the vendor is solid. Build a custom Shopify app when the workflow is yours alone, or when the system you need to reach has no native connector. Most stores end up with both, and the skill is knowing where the line sits.

When is a public app the right choice?

A good public app is shared work. Thousands of stores use it, so edge cases get found and fixed by someone else. The vendor keeps up with Shopify changes, and you get support without writing a line of code.

Reach for a public app when the job looks like this.

• Reviews, loyalty, subscriptions, search and email capture. These are common patterns with mature options.
• A connector to a well-known platform, where the vendor already maintains the sync.
• A feature you want this month, not after a build.
• A job where the vendor's roadmap is likely to go further than you would on your own.

Before you install, check the basics. Is the app actively updated? Does support reply? Does it load scripts on every page, or only where it's needed? Can you remove it cleanly if it doesn't work out?

When does a custom Shopify app make sense?

Custom work earns its place when the process is specific to your business. If you'd have to bend your operation to fit an app, the app is the wrong shape.

We see four common reasons.

1. No connector exists. On Surrey Cricket Club, the print on demand providers had no native Shopify integration. We built a custom export that routes orders to them with no manual copying. Our guide to Shopify for sports clubs covers that setup in more detail.
2. The logic is yours. Trade pricing rules, delivery windows and account-specific workflows rarely match an off-the-shelf app. On Fáilte Foods we built date-based pricing for delivery processing and a favourites list for reordering.
3. An ERP has to stay in charge. When Business Central, Odoo or NetSuite owns stock and price, the sync has to follow its rules, not a generic mapping.
4. You're paying for several apps to do one job. A single focused tool can be easier to run than three apps that each cover part of the process.

What does building a custom app involve now?

The route has changed. From the 1st of January 2026, new custom apps can't be created directly in the Shopify admin. Existing ones keep working. New custom apps are built in the Dev Dashboard and then installed on the store. We covered the detail in our note on the legacy custom apps deadline.

For a small admin tool, Sidekick is now an option too. You describe what you need and it writes a single-page tool that runs inside the admin. We wrote up where Sidekick fits for custom apps and Flow, and where a developer still helps.

Checkout logic is its own case. Discount, shipping and payment rules belong in Shopify Functions. If you still rely on Scripts, our guide to moving from Scripts to Functions covers that switch.

A proper custom app build usually runs like this.

1. Map the process with the people who do it every day.
2. Decide which system owns each piece of data.
3. Build against Shopify's APIs and test the awkward cases, such as partial refunds or records created in two places.
4. Install on a development store, then on the live store.
5. Document it and agree who watches it after launch.

Questions to ask before you decide

These questions settle most decisions in one conversation.

• Is this workflow the same for most Shopify stores, or specific to us?
• Does a maintained public app already connect to the system we need?
• What happens to orders if the app stops working for a day?
• Who fixes it, and how quickly, when Shopify or the other system changes?
• Are we comparing like with like? A monthly app fee against a one-off build plus upkeep.
• Could a public app cover most of it, with a small custom piece for the rest?

If the answers point both ways, that's normal. The last question is often the right answer.

The middle route most stores take

A mixed setup is usually the most practical. Public apps handle the common jobs well. A small custom app fills the one gap that's unique to you.

That keeps the custom code small, which keeps it cheaper to own. It also means you're not rebuilding something a vendor already maintains for thousands of stores. When we audit a store, we often remove apps as well as add them.

The pattern that causes trouble is custom code nobody owns. An app built years ago by someone who has moved on, with no documentation, doing something critical in the background. If that sounds familiar, the first job is finding out what it does and who should look after it.

Where parallel helps

We build custom Shopify apps and ERP integrations, and we tell you when a public app is the better call. The people who scope the work build it, and they can stay on to look after it. See how we approach apps and integrations.

If you're weighing up a build against an app right now, book a call and bring the workflow. We'll tell you which way we'd go and why.