Shopify feature request: theme change, app or custom app?

Define one requirement that can pass or fail

Use an actor, trigger and result: When a shopper buys two identical totes with different gift messages, fulfillment must see the right message against each tote. Add the exception cases before asking for a route or price.

Separate additional requests into their own records. Product care copy editable by merchandising, a gift message entered by a shopper, an eligibility rule and a warehouse notification do not share the same data owner or execution point.

For each record, write who supplies the value, who may edit it, who consumes it, how long it must remain available, and what happens if it is missing or invalid. Define an observable acceptance case and a failure response. “Works with our warehouse” becomes useful only when the payload, destination field, retry behavior and operator view are specified.

Separate data storage, display and authority

Merchant-maintained product information can belong in native structured data. Shopify documents metafields for extending products and other resources, with care instructions as an example. Metafield documentation. A display component can read that data; it does not follow that every custom content field needs a hosted app.

Shopper input is different. The Ajax Cart API supports line-item properties, and two lines can share a variant ID while differing in properties. Cart API reference. A single order note is therefore a poor proposed destination when the requirement is explicitly per item. You still need to demonstrate that the correct value reaches the order and the actual fulfillment tool.

Transaction authority is a separate question again. If the rule must decide eligibility, pricing or permitted checkout behavior, require an appropriate supported Shopify execution point. A label or browser check can guide a shopper but is not acceptance evidence that every transaction path enforces a rule. Functions provide backend logic targets, subject to their capability and distribution restrictions. Functions overview.

Choose a route on the correct surface

These categories can combine. An app can provide a theme extension for input while its service handles integration. “App” and “extension” are not competing architectural labels: name the installed software, the surface it extends, and any service it depends on.

Shopify documents theme app blocks, embeds and direct code injection, with theme/page/section compatibility limits. Theme app methods. A public app's advertised feature is only a candidate until it passes your requirement and exception cases. A custom proposal needs the same proof.

Verify plan, distribution and version before estimating

For Functions, stores across plans can use App Store public apps containing Functions; custom apps containing Function APIs require Plus, and some capabilities add their own restrictions. Functions availability. Record the exact API target and app distribution, not just “custom discount.”

For UI, information, shipping and payment checkout pages are Plus-only app surfaces. Some thank-you, order-status and customer-account customization apps are available on Basic or higher. Checkout/account app availability. A theme edit cannot substitute for a missing checkout extension target.

For new custom apps, use current creation instructions. Shopify stopped new legacy custom-app creation in admin on January 1, 2026 and directs new creation to Dev Dashboard; existing legacy apps continue. Dated creation change. This does not mean a working old integration should be replaced without a separate reason.

Request the necessary permissions, data categories, API versions, hosting and distribution in the proposal. Challenge permissions that exceed the task. Keep secrets server-side and outside the requirement worksheet. Shopify's versioned API schedule and unversioned surfaces require different upkeep checks. Versioning reference.

Also record the actual app model: an App Store public app, a custom-distribution app, a store-organization Dev Dashboard app, or an existing legacy admin-created app. The distribution table distinguishes public/custom installation scope and says legacy admin-created apps cannot use extensions. App distribution capabilities. Do not apply one model's access or extension rules to another.

Add a protected-data gate for warehouse integrations

Before choosing a warehouse connector, list the minimum fields the warehouse actually needs. Separate order/line identifiers, quantities, SKU and gift text from recipient name and shipping-address components. Add email or phone only if the destination has a documented need. Do not request the whole customer profile by default.

Shopify treats name, address, email and phone as protected fields. Its developer table distinguishes public-app review, custom-app access and plan-dependent admin-created custom-app access; unavailable fields can be redacted or accompanied by GraphQL errors despite HTTP 200. Protected customer data guidance. The Help Center separately says Grow or higher for Custom Level 2 PII apps. Those differently scoped statements do not establish that every new custom app requires Grow or Plus. Resolve the proposed app type and store's eligibility before accepting the route.

Save the actual app ID/type, creation organization, distribution/install route, API/version, requested and granted scopes, required protected fields, approval or eligibility evidence, and a dated representative response check. A vendor saying it has the scope is not proof that the warehouse receives those fields. If a required field is unavailable or redacted, defer that route or agree an alternative workflow; never silently ship with invented values.

Make ownership an operating responsibility

A custom app does not automatically establish who owns its code or can operate it. Put the agreed deliverables, licenses, source access, data export, hosting account, deployment access, documentation and handover responsibilities in the engagement. Record third-party dependencies and what happens if the provider changes.

For a public app, check subscription/usage charges, export format, uninstall effects, vendor support and whether critical data remains accessible. For theme work, record the files or extension involved and the retest needed when the theme changes. For a background service, name a person who can see failed work, reconcile it and contact the destination-system owner.

Separate business acceptance from technical maintenance. Merchandising can own the care wording while a developer owns the display component. Operations can own warehouse exceptions while the integration maintainer owns delivery recovery. “The agency handles it” is too vague for either.

Complete a feature-placement worksheet

Use one row per independently testable requirement. Copy these fields into your project record:

• Task: ID, actor, trigger, expected result and exception cases.
• Data: source, exact minimum field inventory, protected-field classification, editing owner, storage location, consuming system and retention/export requirement.
• Authority: display guidance or enforced rule; named execution surface.
• Eligibility: plan, theme/page/section, actual app type and creation/distribution route, API target/version, requested/granted scopes, protected-field approval or eligibility evidence, and representative returned-field check.
• Alternatives: native evidence, public-app evidence, custom-route evidence and reasons for rejection.
• Operation: recurring dependencies, maintenance owner, failure/recovery behavior and handover deliverables.
• Acceptance: representative case, saved evidence, approving operator and unresolved decision.

A one-time import can be the right route when the job is a finite data transformation. Ask whether any continuing behavior actually remains before adding a permanent app. If the essential capability has no eligible target or verified vendor support, mark it unresolved and investigate before accepting the build scope.

Validate in the order failures become expensive

1. Confirm the task and data. Have the consuming operator approve the sample values and expected result.
2. Confirm surface eligibility. Verify plan, extension target, theme compatibility, actual app model and access in official/vendor documentation. For protected data, save approval/eligibility and representative field-return evidence.
3. Try the smallest feasible route. Check native controls and existing apps against the same cases used for a custom proposal.
4. Follow data end to end. Test missing/invalid input, two distinct lines, edits and the relevant cart/checkout paths in an agreed test environment.
5. Exercise failure. For integrations, include duplicates, delayed/out-of-order events, destination downtime and missing/redacted required fields. Shopify says webhook ordering and delivery are not guaranteed and recommends reconciliation. Webhook behavior.
6. Accept handover. The named operator must find failed work, and the maintainer must have agreed source/access and recovery instructions.

Accept the feature only when the observed behavior, documented limitations and responsible owners match the requirement record. Save failed cases too; they explain why a cheaper-looking route was rejected.