A custom Shopify app should solve a clearly defined business workflow. Before development, describe the trigger, the data it needs, the action it takes and how your team will recover when that action fails. A small, testable brief is more useful than a long list of features.
Describe one job with a real example
Begin with the manual process you want to replace. For example: when a paid order is ready for dispatch, check its address, send it to the selected courier and show the booking status to operations. That gives the developer a beginning, an end and a person who can approve the result.
Write one ordinary case and three awkward cases. An order can change after booking, a courier can reject an address, and an operator can press the button twice. These cases explain more about the build than the word “automation.”
Use anonymised examples for discovery. You can explain the data structure without sharing access credentials or a full customer export.
Check whether custom development is necessary
Compare the task with existing app capabilities and the workflow tools already installed. A custom build makes sense when the exact business rules, integration or operator experience cannot be covered reliably by that setup. Read our custom app versus App Store app framework for the buying decision.
Confirm the installation route before implementation. Shopify’s distribution documentation distinguishes public apps from custom distribution, which is intended for one store or eligible stores within the same Plus organization. Distribution affects how the app is installed and billed.
Check the merchant’s plan and the chosen Shopify surface before promising a checkout feature. A developer should validate eligibility for the actual requirement.
Map data ownership and the permissions needed
Make a short table of records: order, product, stock, delivery booking and customer. For each, name the source of truth, the stable identifier and whether the app may read, create or update it.
A shipping app may need an address to complete a booking; a pricing report may not. Request access for the task being built and explain why. Define where tokens and operational data live, how access is revoked and how long logs are retained.
Keep corrections explicit. If staff change a delivery address, decide whether the app can update the existing booking, must cancel and recreate it, or should ask an operator.
Make retries safe and failures visible
Assume external services will sometimes be slow or unavailable. Give the workflow a visible status and distinguish pending work from confirmed success. A screen that always says “sent” is not enough evidence that the other system accepted the action.
- Define what prevents the same action happening twice.
- Choose which failures can retry automatically.
- Keep an operator path for rejected or ambiguous requests.
- Record a useful reference without putting unnecessary customer data in logs.
- Agree how missed changes are reconciled after an outage.
These are design requirements for the proposed app, not a claim that every integration shares the same implementation.
Specify acceptance tests and ongoing ownership
Turn the brief into checks a merchant can observe: an eligible order is processed once, an ineligible order is held with a reason, repeated input does not duplicate the booking, and recovery brings both systems back into agreement.
Agree who owns the source, hosting account, deployment process and support queue. Include recurring hosting and external-service costs in the conversation. Ask how platform changes, permission changes and incidents will be handled after launch.
The first phase should cover a narrow workflow with a clear rollback. Add more couriers, stores or rules after the initial path is understood. The maintenance checklist helps define support once the app becomes part of daily operations.
Questions before you start
What should I send before requesting a custom app quote?
Send the current workflow, the desired result, the systems involved and a few anonymised edge cases. Include the number of stores and who will operate the app. Access can be arranged after the scope is understood.
Can an app connect Shopify to our existing systems?
Potentially. First check the other system’s API, access model and business rules. The brief should name both the integration and its recovery process; connectivity alone does not establish a reliable workflow.