How to develop a Shopify app, or when to hire a developer instead

To develop a Shopify app you scaffold it with Shopify CLI, call the GraphQL Admin API from a backend you host, react to store events with webhooks, and add app extensions or Shopify Functions where your app needs to appear in the admin, checkout or storefront. Building a working prototype is a weekend. Building one that survives real stores, API version updates and App Store review is a different job.

This guide is for merchants and founders deciding whether to build an app themselves, have their in-house developer do it, or hire a Shopify app developer. It covers the stack, the choice between public and custom apps, review, hosting, cost drivers and the mistakes I see most often.

Start with the question: do you need an app at all?

Before writing code, check three cheaper options:

1. Shopify's own features and Shopify Flow. Flow is free on the Basic, Grow, Advanced and Plus plans and handles many "when X happens, do Y" automations. The Send HTTP Request action, available on Grow and above, can call another system without a full app.
2. An existing App Store app. If an app covers the job and is actively maintained, it is almost always cheaper than building and maintaining your own.
3. A small custom app instead of a platform. Many "app ideas" turn out to be a single webhook handler and one admin screen.

Build when the business logic is yours, when off-the-shelf options break on your edge cases, or when the app itself is the product you want to sell.

Public app or custom app?

This is the first real decision, because it changes distribution, review and some platform capabilities.

Since January 1, 2026, new custom apps can't be created from the Shopify admin. They are created in Shopify's Dev Dashboard (usually through Shopify CLI) and installed on the store. Apps created in the admin before that date keep working.

The stack in 2026

Shopify CLI and the app template

Shopify CLI is the entry point. shopify app init scaffolds an app from Shopify's React Router template, shopify app dev runs it against a development store with hot reload and a tunnel, and shopify app deploy pushes the app configuration and extensions to Shopify. App configuration lives in shopify.app.toml and each extension has its own shopify.extension.toml.

shopify app init                 # scaffold from the template
shopify app generate extension   # add a Function, checkout or admin extension
shopify app dev                  # run locally against a dev store
shopify app deploy               # release config + extensions

The template handles OAuth, session tokens for the embedded admin UI, webhook HMAC verification and API client set-up. That saves a week of plumbing, so don't start from an empty folder unless you have a reason to.

The GraphQL Admin API

All store data goes through the GraphQL Admin API: products, orders, customers, inventory, metafields, discounts, fulfillment orders and so on. The REST Admin API has been legacy since October 1, 2024, and new public apps have had to use GraphQL only since April 1, 2025. Don't build new work on REST examples you find in old blog posts.

query RecentOrders {
  orders(first: 20, sortKey: CREATED_AT, reverse: true) {
    nodes {
      id
      name
      displayFinancialStatus
      totalPriceSet { shopMoney { amount currencyCode } }
      lineItems(first: 50) {
        nodes { sku quantity }
      }
    }
  }
}

Two parts of the API matter as soon as you have real data. Rate limits are cost-based, so query only the fields you need. Bulk operations export or import large data sets asynchronously instead of paging through thousands of requests.

Webhooks

Webhooks tell your app when something changes: orders/create, refunds/create, products/update, inventory_levels/update and so on. You declare subscriptions in shopify.app.toml. Three rules apply:

• Verify the HMAC on every HTTPS delivery. The template does this for you.
• Expect duplicates. Shopify can deliver the same webhook more than once. Make processing idempotent, or deduplicate on the X-Shopify-Webhook-Id header.
• Acknowledge quickly and process asynchronously. Put the payload on a queue and return 200, then do the slow work, such as calling an ERP, in a worker.

Webhooks are a signal, not a ledger. A robust app also reconciles on a schedule, because deliveries can be missed while your app is down.

App extensions

Extensions put your app inside Shopify's surfaces without touching theme code:

• Admin UI extensions: actions and blocks on order, product and customer pages.
• Checkout UI extensions: see Checkout UI extensions.
• Customer account UI extensions: blocks on the Order status, order list and profile pages.
• Theme app extensions: app blocks and app embeds for the storefront. This matters because Shopify is deprecating script tags: from October 1, 2026 apps can't create or update them, and on March 1, 2027 Shopify stops injecting them into storefronts.
• Web pixels: analytics and conversion tracking that runs in a sandbox.

Shopify Functions

Functions are small WebAssembly modules that Shopify runs inside its own backend to change discount, delivery, payment, validation and cart logic. They replace Shopify Scripts, which stopped running on June 30, 2026. See the Shopify Functions guide.

Billing

A public app charges merchants through Shopify, either with Shopify App Pricing (plans you configure in the dashboard) or through the GraphQL Admin API's billing mutations. A custom app is usually paid for by contract with the merchant, outside Shopify.

App Store review

If you want a public app listed on the Shopify App Store, it goes through review. Plan for these requirements from the start:

• the mandatory privacy webhooks (customer data request, customer redact and shop redact) are implemented;
• the app uses current, supported APIs, which means GraphQL and no deprecated resources;
• it asks only for the access scopes it needs, and justifies protected customer data access;
• onboarding works on a fresh store, with no manual steps on your side;
• uninstalling cleans up after itself, including theme app extensions rather than edited theme files;
• the listing describes what the app actually does, and billing goes through Shopify.

Review is not a one-off. Apps that keep calling unsupported API resources after a version's deadline get warnings shown to merchants and can be delisted, so budget for keeping up with API versions. Shopify releases a new version every quarter.

Hosting

Shopify runs your extensions and Functions, but you host the app backend yourself. The React Router template runs on any Node.js host. For production you need:

• a database for sessions and your own data;
• a queue or job runner for webhook processing and scheduled reconciliation;
• logging and alerting that someone actually looks at;
• secrets management for the API key and secret, and for any third-party credentials.

For a custom app for one store the infrastructure can be small. For a public app, multi-tenant data isolation and the GDPR webhooks are not optional.

What usually goes wrong

Most failed Shopify apps are not failed because of the hard parts. They fail on these:

1. No idempotency. A retried webhook creates a second invoice in the accounting system. Every write to an external system needs a key that makes a retry safe.
2. Paging instead of bulk operations. The nightly sync that worked on a development store with 50 products times out on 40,000 variants.
3. Ignoring API versions. The app is pinned to a version that falls out of support, and something breaks a year later.
4. Theme edits instead of theme app extensions. Code injected into theme.liquid survives until the merchant changes theme, then fails silently.
5. No reconciliation. Webhooks were missed during an outage and nobody noticed the missing orders until month end.
6. Building a public app for one customer. It goes through review and multi-tenant design it doesn't need. Build a custom app first and turn it into a product later if other merchants want it.
7. Underestimating the unhappy paths. Partial refunds, order edits, exchanges, multi-currency, B2B, bundles and split fulfillments are where integrations break.

What drives the cost

Whether you build it yourself or hire someone, these are the things that decide the effort:

• Number of systems and the direction of sync. One-way order export is much simpler than a two-way inventory and pricing sync.
• Quality of the other system's API. A documented REST or GraphQL API with sandboxes is cheap to work with. A SOAP endpoint or file drop with no test environment is not.
• Edge cases in scope: refunds, exchanges, B2B, multi-location, multi-currency, bundles.
• Extensions and Functions. Each surface is its own build and test cycle.
• Public vs custom. A public app adds review, billing, onboarding, multi-tenancy and support.
• Ongoing maintenance. Quarterly API versions and platform deprecations don't stop after launch.

Build it yourself vs hire a developer: a checklist

Build it in-house if most of these are true:

• you have a developer who has shipped a production web app with OAuth, queues and a database;
• the app is core to your product and you want the knowledge in-house;
• you have time to learn Shopify's API versions, extension types and review rules;
• someone will own maintenance after launch.

Hire a Shopify app developer if most of these are true:

• the job is an integration or checkout change your team will build once and rarely touch;
• the deadline is set by something outside your control, such as a platform sunset, a peak season or a new ERP go-live;
• you need someone who already knows where Shopify's edge cases are;
• you want a clean hand-over: a repository, documentation and a runbook, not a dependency on one person.

A middle path works well too: a developer builds the first version and the foundations, such as authentication, webhooks, queues and reconciliation, then your team extends it.