Before You Commission Shopify App Development
Choose between Shopify Flow, a supported app, and custom development using plan checks, a warehouse retry demonstration, and clear maintenance responsibilities.
Choose custom Shopify app development when a necessary store workflow cannot be handled reliably by native settings, Shopify Flow, or an existing app, and you have someone responsible for maintaining it. Before commissioning the build, require proof that it can run on your plan, recover from interrupted work, and be handed to another developer.
If your team copies orders into a warehouse system every afternoon, those conditions matter more than a polished app dashboard. This guide gives you a brief to send to suppliers and a demonstration to request before accepting their solution. The warehouse example is a proposed evaluation exercise, not a client case study or a claim about a particular integration.
The brief to send before asking for a quote
Write the business rule in a sentence: “Send eligible orders to our warehouse, show which ones were accepted, and let operations resolve exceptions without exporting everything again.” Then make “eligible” precise. Name the payment, review, location, and cancellation conditions your team actually uses.
I would attach the following information to that request:
- Starting event: what should cause work to begin, and what must already be true?
- Destination: which system receives the order, and which record proves acceptance?
- Exceptions: what should happen to missing product mappings, rejected addresses, and orders changed after submission?
- Operator: who sees unresolved work, and who is allowed to retry or cancel it?
- Boundary: which activities remain manual, including any shipping or payment decisions?
Use a small set of anonymized examples, including an ordinary order and the awkward orders your team already handles. Ask every supplier to describe the same cases. Comparing one vendor's complete workflow with another vendor's installation price tells you very little.
Keep the first version narrow. “Connect our systems” is difficult to accept or reject. “Export eligible orders and reconcile warehouse acceptance” gives both parties a visible outcome. Inventory updates, returns, and supplier purchasing can be separate decisions with their own rules.
Ask each supplier to justify the implementation
Configure what Shopify already provides
Ask for a demonstration of the existing setting or feature before discussing a new app. If the requested outcome is already available, the work may be configuration, staff training, or a small theme change. Do not turn every manual task into a software product.
For event-driven automation, evaluate Flow. Shopify documents it as a system of triggers, conditions, and actions, including connections to other apps. It is available on Basic, Grow, Advanced, and Plus; its Send HTTP request action requires Grow, Advanced, or Plus. Tasks supplied by custom partner apps require Plus. Check these distinctions in the Flow plan requirements.
Install Flow, then open Apps > Shopify Flow to inspect candidate workflows with your implementer. Use Shopify's workflow creation guide to identify the trigger, conditions, and actions. Our Flow templates and custom-app boundaries guide helps narrow that evaluation.
A visual workflow still needs an answer for failure. If Flow calls an external service, ask who maintains that service and how staff will know its work finished. A workflow diagram alone is insufficient evidence of warehouse acceptance.
Buy an existing app when it passes your actual cases
Invite an app vendor to run the same examples. Ask about your warehouse, locations, product identifiers, order changes, and support hours. Prefer a supported product when its behavior matches the requirement and your team can operate it.
Do not commission a replacement just because an app has features you will not use. Instead, identify the specific behavior that disqualifies it. “We cannot see rejected orders” is actionable. “We want something custom” does not establish a business need.
Commission the missing part
Custom development becomes a sensible candidate when the remaining requirement is important, specific, and demonstrably unsupported by the alternatives. You might retain an existing app and commission a focused connection around it. Require the proposal to identify the part it owns and the systems it depends on.
For a warehouse integration, I would prioritize accepted-order records and exception handling over a bespoke reporting dashboard. If nobody can maintain the result, keep a supported app or a documented manual process while you resolve ownership.
Reject an infeasible proposal before comparing prices
Have the supplier write down your Shopify plan, required data, deployment method, and every store that will install the app. These are feasibility checks, not details to postpone until development.
Shopify's distribution documentation permits custom distribution to one store or multiple stores belonging to the same Plus organization. Public distribution supports installation across multiple stores and has a review requirement. The chosen distribution method cannot simply be changed afterward. A proposal for several independent stores therefore needs an explicit distribution answer.
Checkout logic needs another check. Under Shopify's Functions availability rules, stores on any plan can use public App Store apps containing Functions, while custom apps containing Function APIs require Plus. Individual capabilities can have further restrictions. Rebuilding a public discount app privately is not automatically feasible on the same plan.
For an order integration, verify access to the customer information it needs. Shopify's app guidance currently requires Grow or higher for Custom Level 2 personally identifiable information apps. Have the implementer confirm the exact fields and access requirements before promising an address-dependent warehouse workflow.
That guidance also places new custom-app creation and management in the Dev Dashboard. Do not accept an old tutorial's admin screenshots as a deployment plan. Ask who controls the app, who can manage it, and how your business retains access when personnel change.
The demonstration that separates a connection from a usable integration
Request this demonstration in a test environment, with warehouse dispatch disabled. Ask the supplier to arrange the failures; your operations team should observe the outcome rather than experiment with live customer orders.
Shopify explicitly documents that webhook deliveries can repeat and recommends idempotent processing: receiving the same notification again should not produce an additional business effect. Its delivery guidance also discusses reconciliation to retrieve missed data. Those are useful foundations, but your acceptance test must reach the destination system.
First, prove the ordinary order
Submit one eligible test order. Have the supplier show its Shopify identifier, the integration's record, and the warehouse's accepted-order identifier. Check products, quantities, and the destination details required by your workflow. Write down what the operator sees when the process is complete.
Define success as the business outcome. A “request sent” message should not satisfy a requirement that the warehouse accepted the order. If the destination processes requests later, ask how the integration eventually confirms acceptance or exposes rejection.
Then lose the reply after the warehouse accepts it
Ask the supplier to simulate the destination accepting that order but its response failing to reach the integration. Then demonstrate the proposed retry procedure.
For the same export operation, a retry should resolve to the existing warehouse record or stop for investigation; it must not silently create a second dispatch instruction. This is my recommended acceptance requirement, not a claim that Shopify enforces the destination's behavior.
Require evidence from both sides. A clean integration log is not enough if the warehouse now contains two orders. Ask how the solution recognizes an operation already accepted externally, even when its own local record was not updated. Record the original warehouse ID beside the retry result so the demonstration leaves evidence your team can review later.
If the destination offers neither a reliable way to identify repeated requests nor a way to look up the original operation, require a visible manual reconciliation step. Do not accept “retry until successful” without a description of what prevents duplicate work.
Check changes and unresolved work
Next, change an order after its first export. Ask the supplier to demonstrate the agreed update or exception process. Preventing a duplicate original export must not hide a legitimate later change. The brief should say which changes can be synchronized and which require human approval.
Finally, interrupt the integration, restore it, and compare eligible Shopify orders with destination records. Request a visible list of unresolved cases. Let an operations colleague work one case using the proposed instructions, without the developer explaining every click.
This also applies when the proposed solution uses Flow. Shopify's HTTP action documentation says it waits up to 30 seconds for a response and retries after a timeout. Ask how the receiving service handles a repeated request. Choosing Flow does not settle that external-system question.
Compare what you will operate, not just what gets built
Request separate scope lines for discovery, implementation, installation, monitoring, maintenance, and handover. Use actual supplier quotes and published app prices; there is no useful universal development price for these different responsibilities.
I would ask for the following commitments before approving a custom build:
- Business ownership: a named person approves order eligibility and exception rules.
- Technical ownership: a named provider handles faults, dependency updates, and Shopify compatibility work.
- Operational visibility: staff can identify pending, accepted, rejected, and unresolved work using agreed definitions.
- Recovery: written instructions explain how to pause new exports and reconcile outstanding work before restarting.
- Handover: access arrangements, source-code rights, deployment instructions, configuration, and support contacts are explicit.
“Custom” does not establish ownership of the code or remove running costs. Put those terms in the agreement. Ask whether you can appoint another maintainer and what they would receive. Treat access to the deployed application and the ability to rebuild it as separate handover questions.
When replacing an existing integration, agree which system exports orders during the transition. Keep a record of the last confirmed export and anything still unresolved. Our app removal and cleanup guide covers why removal deserves its own review; for this project, also require a destination-side reconciliation plan.
Make the decision from the evidence
Choose configuration or Flow when it expresses the required rules clearly and the complete process passes your checks. Choose a supported app when it handles the real cases and provides an acceptable operating model. Commission a custom component when the remaining gap justifies owning it.
Your final approval packet can be short: the agreed business rule, feasibility notes, demonstration results, unresolved limitations, and named owners. A proposal that explains its limits is easier to assess than one that promises to connect everything.
If you need help evaluating that packet, our Shopify development services can help scope the integration and its acceptance criteria. Start with the difficult order and the recovery question. The right implementation is the one your team can confidently operate after the developer leaves the call.