Shopify app development cost: what it actually runs to

Shopify app development cost varies enormously, and the variation is explainable rather than mysterious. Here are realistic brackets, what moves you within them, and the ongoing costs most quotes leave out.

Treat these as planning brackets, not quotes. Regional rate differences apply exactly as described in developer rates.

Rough brackets

The gap between the first and last rows is the difference between custom and public, and it's mostly not code — it's review, support, compatibility and marketing.

What drives the number

The build itself is the same shape in both cases — creating an app covers the sequence. What moves the number:

How many systems it talks to. One app reading Shopify data is straightforward. An app synchronising Shopify with an ERP is an integration project with an app-shaped front end, and the integration is the expensive half.

Data volume. An app that works on 500 products and one that works on 500,000 are different builds. Rate limits, pagination and bulk operations stop being details and become architecture — see the Admin API guide.

Real-time or batch. Near-real-time needs webhooks, queues, retries and reconciliation. A nightly job needs a cron and a log file. This single decision can double a quote.

Which extensions. Each surface — checkout UI, admin UI, theme blocks, Functions — is its own build, its own testing and its own review.

How much UI. An app with a settings page is cheap. An app with dashboards, reporting and bulk editing is a web application.

Whose rules. "Apply the discount" is a day. "Apply the discount according to our pricing policy" is a fortnight, because the policy has never been written down and has fourteen exceptions.

The costs nobody quotes

• Hosting. An app is a service you run. Modest for a custom app; real for a public one under load.
• Error monitoring and logging. Not optional for anything touching orders.
• API version maintenance. Shopify rotates versions. An unmaintained app breaks — and the cost of not budgeting for this is an emergency, at emergency rates.
• Support. For a custom app, whatever arrangement you have with the client. For a public app, a permanent function.
• App Store review cycles. Budget for at least one rejection and a resubmission.

Ongoing cost for a public app runs 20–40% of the original build per year. Quotes that omit this aren't cheaper; they're incomplete, which is the same pattern as any quote missing testing and handover.

How to make a quote meaningful

The difference between a wide range and a fixed price is how well the problem is described. Concretely, provide:

1. The outcome in business terms, not the solution you imagined.
2. Which systems are involved, and whether they have documented APIs.
3. Data volumes — products, orders per day, customers.
4. How fresh the data must be. "Within an hour" and "within five seconds" are different budgets.
5. Who owns which field, if two systems both hold the same data. This one decision prevents most integration failures.
6. What happens on failure. Retry, alert, queue for a human?

How to write a project brief covers the general version. Points four and five are the ones specific to apps, and they're where vague briefs become expensive.

When not to build one

The cheapest app is the one you didn't need. Before commissioning, check that a store app doesn't already do 90% of it, and that the workflow itself isn't the problem. Custom apps vs third-party apps is the decision framework — and a developer who won't tell you when to buy instead of build is one worth being careful with.

The expensive part of an app is rarely the feature you asked for. It's the error handling, the data volume and the edge cases in your own business rules.