Custom Shopify App Development

A private app serves one store and can be tailored to that merchant's exact process. A public app has to install cleanly on stores it has never seen, survive different themes and plan capabilities, and pass a review. The same codebase can begin private and later become public, but that transition is a project rather than a setting.

We ask early which one is intended. A private app can take shortcuts in onboarding and support that a public listing cannot. A public app needs tenant isolation, a billing model, a privacy policy and an uninstall path from the first commit.

Embedded apps run inside the admin, so the interface has to feel like part of it. We use the platform's component language, its navigation patterns and its session token flow. A screen that opens in a new browser tab breaks the context staff are working in and usually gets abandoned.

The backend still does the real work. Admin pages call our service with a session token, the service resolves the shop, and every query is scoped to that shop. We keep heavy reports off the initial render, paginate lists and show progress for anything that takes more than a moment.

A webhook is a delivery attempt, not a guarantee of exactly-once processing. We verify the signature, store the event identifier and reject a duplicate before it creates a second record. The handler writes to a queue and returns quickly, so a slow downstream system does not cause the platform to retry into a timeout.

Ordering is not promised either. A cancellation can arrive before the order it refers to, so handlers fetch the current state rather than assuming sequence. A reconciliation job compares the app's view with the platform's on a schedule, because a missed webhook should be detected rather than discovered by a customer.

Extensions put functionality where the work happens: an action beside an order, a block on a product page, a field in checkout where the merchant's plan permits it. Each extension target has its own constraints, review rules and supported surfaces, so the choice is made per use case rather than as a general preference.

Checkout extensions are the most restricted. Not every plan exposes them, and the allowed changes are narrower than a storefront theme. We confirm what the merchant's current setup supports before promising a checkout change, and design a fallback for stores that cannot use it.

If the app charges merchants, the billing relationship belongs inside the platform's billing system. Recurring charges, usage records and trials are created through the API, and the app checks the active subscription before serving paid features. That keeps the merchant's invoice in one place instead of a second payment relationship.

We do not quote platform charges or app-store fees, because those are set by the provider and appear on the merchant's own bill. Our fee covers the app's design, build, review preparation and handover. The billing logic is tested with test charges before a real merchant sees it.

A public app needs a listing that explains what it does, a privacy policy, support contact details and a working install and uninstall flow. Reviewers check that requested scopes match the features, that the app does not break the admin, and that a merchant can remove it without leaving data stranded.

We prepare the listing copy, screenshots, test instructions and a demo store where needed. The most common delay is a scope the app requests but never uses. We trim the permission list to what the code actually calls, which also makes the security story easier to explain.

The floor covers one store, a defined workflow, an embedded admin screen and the webhook or API integration behind it. Multiple stores, billing, checkout extensions, a public listing and data migration are additional scope. A public app costs more than a private one because tenancy, onboarding and review work are real features.

We price the app as custom software rather than as a theme add-on. The difference matters when the workflow changes: an app with a documented data model can be extended, while a pile of scripts attached to a theme usually cannot.

Uninstalling an app should have a defined consequence. Some data must be deleted on request, some must be retained for accounting, and some can be exported before removal. We write that policy into the app and the privacy documentation rather than leaving it to an operator.

The merchant owns the store data and the app credentials; the code is handed over with hosting instructions. If the app later becomes a product, the same repository can be listed publicly, but only after the tenancy and review work is funded as its own phase.