Launch is the start of operations
A custom Shopify app can be feature-complete and still need maintenance. The platform changes, connected vendors change, certificates expire, payloads contain unexpected data, and business rules evolve.
The useful question is not whether maintenance exists. It is how much operational coverage the app needs.
The minimum maintenance layer
Every production app should have five basics:
- A named owner. Someone is accountable for alerts, access and upgrade decisions.
- Error monitoring. Exceptions and failed jobs must reach a person, not disappear into logs nobody reads.
- Health signals. Queue depth, webhook failures and last successful sync should be visible.
- Recovery procedures. The team should know how to replay an event or reconcile missing data.
- A dependency and API review. Versions and security updates need a recurring calendar slot.
This can be lightweight. A private admin tool used by three people does not need the same on-call model as an order integration processing revenue around the clock.
Shopify API versions are a real maintenance clock
Shopify publishes stable API versions quarterly and supports each stable version for a defined period. Shopify recommends selecting a version explicitly and reviewing releases regularly.
An upgrade is more than changing a date in a URL. Deprecated fields, permissions, webhook payloads and extension behavior should be checked in a development store, then deployed with a rollback path.
A practical rhythm is:
- review the developer changelog every quarter;
- check the API health report;
- run automated tests against the target version;
- verify scopes and webhook subscriptions;
- deploy before the current version reaches the end of support.
Webhooks need recovery, not hope
Shopify retries failed webhook deliveries, but persistent failures can remove a subscription. Shopify also expects a fast response, which is why production handlers should verify the request, acknowledge it quickly and process heavier work asynchronously.
Idempotency matters because the same event can arrive more than once. Reconciliation matters because no event system should be treated as a perfect ledger. For an order or inventory integration, a scheduled comparison is the safety net that catches drift.
Three sensible support models
| Model | Best for | Typical coverage |
|---|---|---|
| Quarterly health check | Narrow, stable internal tools | Versions, dependencies, access, restore test |
| Maintenance block | Active apps with regular small changes | Monitoring, fixes, minor improvements |
| Operational retainer | Revenue-critical integrations | Alerts, incident response, upgrades, roadmap |
The agreement should state response expectations, included work and who pays third-party hosting. Avoid vague “maintenance included” promises that define neither ownership nor service level.
Ownership is part of maintenance
The merchant should leave the project with code access, infrastructure access, environment documentation, a data-flow diagram and a runbook. A vendor may operate the system, but the business should not be locked out of its own tooling.
Our custom Shopify app development scopes include this handover by default. The maintenance model is chosen from actual criticality, not added as an automatic subscription.