What actually drives the cost of a Shopify app

This article does not contain a price range. That is deliberate, and it is the most useful thing in it.

Ranges published for "Shopify app development" are built from a sample of projects that have nothing in common with each other, and the number you take away from one becomes an anchor you then negotiate against — usually badly, because you cannot yet tell which end of the range your project sits at. What is worth knowing is what moves the number, so that when you get a real quote you can read it.

The variables, roughly in order of impact

1. Distribution

The single largest factor, and it is decided before any feature is discussed. A custom app installs on one store and can assume that store's catalog, its fulfilment rules, its data quality. A public app has to work for every store that installs it — every assumption becomes a setting, every edge case has to be handled generically, and there is a review cycle between you and each release.

Most of the cost of software is generality. Public distribution buys generality and you pay for it in scope, not in hours per feature. We wrote up how to choose between them separately.

2. How many systems it has to talk to

An app that only reads and writes Shopify is a bounded problem. An app that also has to talk to an ERP, a 3PL and an accounting system is four integrations, and the third-party ones are where the schedule goes: their documentation is worse, their sandboxes are worse, and their failure modes are yours to absorb.

The specific question that predicts cost here is not how many systems, but who owns each one. An API you control behaves. An API a client's vendor controls, with a change window you do not see, does not.

3. Whether it holds state

An app that reads Shopify, computes something, and writes back is meaningfully cheaper than one that keeps its own records. Once you hold data you own migrations, backups, a privacy posture, and the mandatory compliance webhooks doing real deletion work rather than returning 200.

4. What has to be visible

An embedded admin interface is a real front-end project, with Shopify's own design conventions to follow. A scheduled job with a log page is not. A surprising share of what gets scoped as "an app" needs the second and is quoted as the first, because the brief said app.

5. Real-time versus scheduled

"When an order comes in" and "every night" are different systems. Webhook-driven work needs idempotency, retry handling and a way to catch up after an outage, because webhooks can arrive twice, out of order, or not at all. Scheduled work can be simpler and is often enough. This is worth deciding explicitly rather than inheriting from a sentence in the brief.

6. How much of the logic is genuinely known

Where the rules already exist — in a spreadsheet, in a document, in a working process — implementation is the whole job. Where they have to be discovered by interviewing people who disagree with each other, discovery is the job and implementation is the easy part. The second is not more expensive per hour; it is less predictable, which is the thing a fixed quote has to price.

7. The part almost nobody budgets

Shopify releases a new API version every quarter and supports each for a year. An app nobody maintains does not fail gradually — it works, then a version is retired and it stops. Add access token rotation, scope changes when the app grows, and dependency updates.

Whatever the build costs, the honest question is who is responsible for it in eighteen months. Budgeting the build and not the maintenance is the most common way an app becomes expensive.

What to specify before asking anyone for a number

Quotes become comparable when the brief is specific about these, and vague when it is not:

The distribution. One store, or the App Store.

The systems. Named, with who owns each and whether their APIs are documented.

The trigger. Real-time on an event, or on a schedule.

The data. What the app stores, and for how long.

The surface. Embedded interface, or a job with a status page.

The one rule that must never break. Every project has one — never oversell, never expose wholesale pricing to retail, never double-charge. Say which, because it determines how much testing is warranted.

Who owns it afterwards. Your team, or the people who built it.

Reading the quote you get back

A quote worth comparing has a scope you recognise, an explicit list of what is excluded, a named ongoing arrangement, and a statement about who holds the code and the Shopify Partner account it lives in.

A quote that is only a number and a duration is not cheaper. It is just less specific about what happens when the scope turns out to be larger, and that conversation always occurs.

If you have the seven answers above, most of the estimate is already written. Send them to us and you will get a scope back rather than a range — and if the honest answer is that you do not need an app, we would rather say so at that stage than after.