When a custom Shopify app is the right call

Most people arrive at this question already having decided the answer, and usually the wrong way. Either an app from the App Store is treated as free because it costs forty dollars a month, or building is treated as the serious option because it sounds like engineering. Neither is a decision. A decision means naming what each of the three routes actually costs and picking the cheapest one that survives the next two years.

There are three routes, not two: install something, configure something you already have, or build. The middle one is the one people skip, and it is frequently the right answer.

What an app from the store actually buys you

An installed app buys you a maintained answer to a problem you do not want to own. Somebody else keeps it working when Shopify changes an API version, absorbs the support load, and handles the edge cases you have not thought of yet. For anything that is genuinely a commodity — reviews, backups, a basic upsell widget, transactional email — that is an extremely good trade and building is close to indefensible.

What you are actually buying is somebody else's roadmap. That is fine when your requirement sits in the middle of their roadmap and stays there. It stops being fine at the exact moment your requirement becomes the thing they will not build, because it matters to you and to nine other merchants, and they have forty thousand.

The costs people forget are not the subscription. They are the storefront weight an app adds when it injects scripts, the data it takes custody of, the theme edits it leaves behind after uninstall, and the fact that five apps solving five adjacent problems will eventually contradict each other in the cart. Ten apps at thirty dollars is not three hundred dollars a month, it is three hundred dollars a month plus every script those ten apps put on the page.

Where configuration runs out

Before building, exhaust what the platform already does. A surprising share of "we need a custom app" requests are solved by native features nobody enumerated: metafield and metaobject definitions for structured product data, Shopify Flow for event-driven admin automation, discount combination rules, markets for regional pricing and catalogues, customer segments, bundles, selling plans, delivery profiles.

Configuration runs out in three recognisable ways, and it is worth learning to see them coming.

The first is expressiveness. The rule you need cannot be written in the vocabulary the settings offer. "Ten percent off, but not on gift cards, and not stacking with the loyalty discount, and only on the second unit onward" is a rule most promotion engines cannot state, regardless of how many checkboxes they have.

The second is placement. The logic has to run somewhere no app can reach. Checkout pricing is the clearest example: no external service can reprice a cart from outside, which is why that work belongs to Shopify Functions rather than to an integration with a webhook.

The third is ownership of the data. The moment the rule depends on a system that is yours — an ERP, a pricing service, a B2B account structure, a warehouse — no third party can encode it, because half the inputs live behind your firewall.

What owning an app actually costs

This is where most build decisions go wrong, because the estimate covers the feature and not the app. The feature might be two weeks. The app around it is not optional and it is not small.

Auth and sessions. An embedded app has to handle the OAuth install, store and refresh tokens, verify session tokens on every request, and behave correctly when a merchant reinstalls, changes plan, or has two staff accounts open. This is a well-trodden path, and it is still real work with real security consequences if it is done casually.

Webhooks. Webhooks are the part that quietly decides whether an app is trustworthy. They arrive out of order. They arrive twice. They fail to arrive and get retried later. Every handler you write has to verify its HMAC, be idempotent, and return quickly — meaning the work goes on a queue rather than in the handler. An app whose order webhook does its processing inline is an app that will lose an order the first busy afternoon.

Billing. If the app charges merchants and is public, charges go through Shopify's Billing API — recurring, usage-based or one-time. That means modelling plans, handling upgrades and downgrades mid-cycle, and reconciling what Shopify says the merchant is on against what your database thinks.

Review. A public app is reviewed before it lists, and the requirements are not only functional: correct OAuth, the mandatory compliance webhooks, a privacy policy, a working support flow. Approval is Shopify's decision, and no one can promise the date.

Hosting and operations. The app is a service you now run. It needs somewhere to live, a database, logs you can search, alerting when webhook processing backs up, and a plan for the day an API version is deprecated. That last one is the recurring cost people never budget: an app is not finished, it is maintained.

Public, custom, or private — three very different bills

"Build an app" is three separate decisions wearing one name, and the distribution model changes the cost more than the feature does.

A custom or private app for one store

Distributed to a single store, not listed, not reviewed. No billing to build, no listing assets, no review timeline, and a much smaller compliance surface. This is what most merchants actually need when they say "app", and it is the cheapest way to own logic that is genuinely yours. It is the shape of most of the work described on our private apps page.

A public app

Listed on the App Store, installable by anyone, reviewed, billed through Shopify. You are now running a product with tenants — support, onboarding, versioning, and the certainty that some merchant will use it in a way you did not design for. Building this because one merchant needs a feature is the most expensive mistake in the space. Building it because you intend to sell it is a different project entirely, with a different plan.

A Function that happens to need an app around it

Functions are deployed through an app, which confuses the question. If all you need is a Cart Transform or a discount rule, the app is a delivery vehicle, not a product: no embedded admin to speak of, configuration in metafields, almost nothing to host. The scoping conversation should separate those two things explicitly, because "we need an app" and "we need a Function that ships inside a minimal app" have wildly different price tags.

The signals that mean build

In practice, these are the ones that hold up:

• The logic is the differentiator. If the rule is a reason customers choose you — how you price, how you allocate stock, how you gate B2B access — it should not live in someone else's product.
• Three or more apps are being stitched together. When the workaround is app A exporting to a sheet that app B reads, the integration is already a system you own without the benefits of owning it.
• The rule has to run inside checkout. There is no configuration path to this. It is a Function or it does not happen.
• Your own data is an input. If half the inputs are in an ERP, a warehouse or a pricing service, no installed app can see them.
• The subscription outgrew the build. A tool at six hundred a month covering thirty percent of what you need is a build that pays for itself, and this arithmetic is worth doing on paper rather than in a meeting.
• Uninstalling would be a crisis. If a vendor disappearing would stop your operation, you already depend on it like infrastructure while paying for it like a subscription.

And the signals that mean do not build: the requirement is common, the app market has three mature answers, the volume is low enough that a human doing it by hand is genuinely cheaper, or nobody has written the rule down in prose yet. That last one is not a joke. A rule you cannot state in a paragraph is a rule you cannot scope, and it is the most reliable predictor of an app that takes three times as long as it should.

The question underneath the question

"Should we build an app?" is rarely the real question. The real one is whether this piece of logic is yours — whether you would want it to survive a vendor going away, whether it encodes something about how your business works, whether anyone else could maintain it without you explaining your operation to them first.

If the answer is no, install something and get on with it. If the answer is yes, own it properly rather than approximating it across four subscriptions and a spreadsheet. Everything on our custom apps page starts from that distinction, and the scoping call usually spends more time on it than on the feature list.