Fixed scope
Fixed price
against a written scope
- Written scope and acceptance criteria up front
- Fixed price against that scope
- Staged delivery with review points
- Change requests priced separately, never absorbed silently
Shopify app development
Public apps for the App Store, custom apps for one merchant, and the extensions that put your functionality where it belongs — the admin, the theme, checkout and the order status page. We maintain seven apps of our own, so we build yours against the same review bar we have to clear.
We ship apps of our own, on the same rules
Seven apps in the Shopify App Store means we have been through listing review, mandatory webhooks, GDPR endpoints, billing edge cases and performance requirements repeatedly — and we have had submissions rejected and had to fix them.
Built to pass review, not to demo well
App Store rejections are rarely about the idea. They are about mandatory compliance webhooks, OAuth handled incorrectly, billing that does not survive a plan change, missing data-deletion endpoints, or an embedded UI that ignores App Bridge navigation.
We build against those requirements from the first commit rather than retrofitting them the week before submission.
See the process
Public app or custom app
A public app is a product: listing, billing, support, versioning and a review process, with distribution in return. A custom app serves one merchant, skips review entirely, and can do things a public app cannot.
These are different businesses, not different sizes of the same project. We will push on which one you actually need before scoping either.
Compare the two
The Shopify app stack we build on
Shopify’s own app platform, current generation. No legacy patterns that will need rewriting at the next platform deprecation.
Remix & the app template
Shopify’s recommended stack for new apps, with session storage, OAuth and webhook plumbing already correct.
Polaris & App Bridge
An embedded admin UI that looks and behaves like Shopify, with navigation, toasts and modals handled by the platform.
Admin GraphQL API
Typed queries and mutations, bulk operations for large catalogues, and cost-aware querying so you do not spend a merchant’s rate limit rendering one screen.
Extensions
Theme app extensions, checkout UI extensions, admin blocks, customer account extensions and Shopify Functions — putting behaviour where the merchant already works instead of behind another admin tab.
Webhooks & compliance
Mandatory GDPR topics, HMAC verification, idempotent handlers and retry behaviour — the things review actually checks.
Billing API
Subscriptions, usage charges, trials and plan changes handled through Shopify’s billing so merchants pay where they expect to.
What an app build covers
The listing is the visible part. These are the parts that decide whether it survives contact with real merchants.
Embedded admin
Polaris UI inside the Shopify admin, with App Bridge navigation, resource pickers and the loading states merchants expect.
Storefront surface
Theme app extensions and app blocks, so merchants add your functionality from the theme editor rather than pasting a snippet.
Built to clear App Store review
Mandatory compliance webhooks, correct OAuth and HMAC verification, billing that survives upgrades, downgrades and reinstalls, plus performance within the Web Vitals requirements for storefront-facing code. Built in from the start, because retrofitting it is how submissions slip by a month.
- GDPR webhooks
- OAuth & HMAC
- Billing edge cases
Scale that does not surprise you
Bulk operations for large catalogues, cost-aware GraphQL, background jobs with backoff, and webhook handlers that are safe to receive twice. The difference between an app that works in development and one that survives a merchant with 200,000 variants.
- Bulk operations
- Rate-limit aware
- Idempotent webhooks
Data & privacy
Minimal data retention, deletion endpoints that actually delete, and a privacy posture you can defend to a merchant’s legal team.
Listing & submission
Listing copy, assets, demo store and the submission itself — including the rework after the first review round.
Public app vs custom app
Different products, not different sizes. Which one you need is usually settled in the first conversation.
| Custom app (one merchant) | Public app (App Store) | |
|---|---|---|
| Who can install it | One store | Any store |
| App Store review | Not required | Required, and iterative |
| Billing | Invoice the merchant directly | Shopify billing, revenue share applies |
| Time to first install | Shorter | Longer — review adds a cycle |
| Ongoing obligations | Whatever you agree | Support, versioning, platform deprecations |
| Access to merchant data | Scoped to one store | Scoped per install, higher scrutiny |
| Distribution | None | App Store listing and search |
| Best when | Bespoke internal workflow | The problem is common across merchants |
How we work
How an app project runs
7 stages. Open any one of them.
Scope and shape
Public or custom, and what it must do.
We settle distribution model, required scopes, extension surfaces and the data you actually need — which is usually less than first proposed.
UX in Polaris
Designed inside the admin, not beside it.
Screens designed against Polaris so the app feels native, with empty, loading, error and no-permission states specified.
Development
On a development store you can install.
Remix app, embedded admin, extensions and background jobs, with a working install on a dev store from early on.
Review readiness
The stage that stops submissions slipping.
Mandatory webhooks, OAuth and HMAC, billing edge cases, performance requirements and the listing requirements — checked against the current rules, not last year’s.
Hardening
At merchant scale, not demo scale.
Large catalogues, rate limits, webhook replay, reinstall and uninstall paths, and plan changes mid-cycle.
App Store listing
Expect a round of feedback.
Listing copy, assets, demo store and submission — then the rework. First-round feedback is normal, and budgeting for it is the difference between a schedule and a hope.
After launch
Platform deprecations are not optional.
API version upgrades, deprecation deadlines, support triage and iteration. An unmaintained app breaks on Shopify’s schedule, not yours.
Ways to engage
Three shapes, depending on how well defined the work is. Every one starts with a scoped written proposal — no work begins on a verbal estimate.
Retainer
Monthly
block of hours
- A block of hours each month
- Prioritized by you, replanned as often as you like
- The same developers month to month
- Reporting on what the hours went to
Time & materials
Tracked time
billed as used
- Billed against tracked time
- Suits discovery, R&D and migrations
- Estimate per ticket before it starts
- Stop or change direction at any point
Rates are quoted against a written scope rather than published as a tier, because the same service costs very different amounts on a five-template store and a five-hundred-template one.
Context
The categories we build for
App work is less category-driven than storefront work, but the merchant’s vertical still decides which edge cases matter.
Fashion & Apparel
Beauty & Cosmetics
Food & Beverage
Jewelry & Luxury
Home & Outdoor
Electronics
Health & Supplements
Subscription
Sports & Fitness
Multi-region
Marketplace & Multi-store
Questions about Shopify app development
Public apps for the Shopify App Store and custom apps for a single merchant, built on Shopify's current app platform — Remix, Polaris and App Bridge, the Admin GraphQL API, theme app extensions, checkout UI extensions, admin blocks, customer account extensions and Shopify Functions. TLX Apps maintains seven apps of its own, so client apps are built against the same review bar.
If the problem is specific to your business, a custom Shopify app is faster, skips App Store review and has no revenue share. If the problem is common across merchants and you intend to sell it, you need a public app and everything that comes with it — listing, support, versioning and platform deprecations.
We build against the review requirements from the first commit — mandatory GDPR webhooks, correct OAuth and HMAC verification, billing that survives upgrades, downgrades and reinstalls, and storefront performance requirements — which is where most rejections come from. Nobody can promise a first-round pass, so we budget a rework cycle into the schedule rather than pretend it will not happen.
Yes, usually starting with an audit: API version currency, deprecation exposure, compliance webhooks, billing correctness and data retention. Those four things account for most of what we find wrong in inherited apps.
Both are supported and often the right surface. Shopify Functions replace legacy script-based customisations for discount, shipping and payment logic; checkout UI extensions are how you add anything to checkout on Plus. Where an extension can do the job, it beats an embedded admin screen.
You do, both. The repository is yours and the Shopify App Store listing sits under your Partner account, not ours.
By storing as little of it as possible. Most app features do not need a copy of the catalogue, and the ones that do can usually hold identifiers rather than content. Deletion endpoints actually delete.
It depends on surface area, extension count and whether App Store review is in scope, so a number here would be meaningless. We scope first and quote against a written scope.
Shopify ships API versions quarterly and supports each for about a year, so an unmaintained app breaks on Shopify's schedule rather than yours. Most clients keep an On-Demand Shopify Support retainer to stay current.
Got an app idea, or an app that needs rescuing?
Tell us what it should do and who it is for. We will come back on public versus custom, the surfaces it should use, and what review will ask of it.