Shopify development stores: client handoffs and beta demos

Shopify development stores are the agency and developer sandbox environment where real work happens before a merchant sees it. Partners use dev stores for client prototypes, beta-feature demos, internal tool testing, and theme development. The setup looks trivial but has meaningful choices that affect the ownership transition, feature availability, and ongoing maintenance.

Two scenarios cover most Partner use cases.

Scenario 1: Client handoff store

An agency creates a dev store for a new apparel client, uploads Shopify's dummy apparel data via CSV to show off the look and feel, gives the store a placeholder name for the moment. The client reviews, approves the direction; agency prepares for full go-live.

The critical question: will this dev store become the production store, or is it throwaway?

The right setup for client-handoff: select "Create a store for a client" during dev store creation. This flag marks the store as eligible for transfer of ownership to the merchant at go-live. When the merchant signs up for paid Shopify, the dev store transitions directly to their production environment - theme, data, apps, settings all intact.

Alternative paths (don't do these):

• Create a general dev store, then rebuild in the merchant's new paid store. Double the work; risks of divergence.
• Create a dev store for yourself, then clone to merchant. Manual, error-prone.

Only the "Create a store for a client" flag gives the clean ownership transfer.

What the dummy data does

Uploading dummy apparel data via CSV gives the client a realistic visual. Variants show correctly, product images populate, collection pages look populated. Abstract "empty catalog" stores are hard for clients to evaluate.

The dummy data stays with the store until production data replaces it. At go-live:

1. Export the production catalog from wherever it lives (external PIM, spreadsheet, legacy Shopify)
2. Delete the dummy products (or bulk-delete via Admin API)
3. Import production catalog via Matrixify, DMF-style tool, or CSV
4. Verify collection assignments
5. Verify theme sections still render correctly

The cutover typically happens in a single session. The client sees familiar look-and-feel but now with real products.

Scenario 2: Beta feature demo store

A client asks the agency to demo a beta feature Shopify released at the latest Editions event. The demo is a 15-minute video call; the feature is new and not yet GA.

The right setup: when creating the dev store, select the "Run demos on Shopify's newest features" option (or equivalent current naming). This flag enables beta features that aren't in GA Shopify. Standard dev stores may or may not have beta access.

With the flag enabled, the store lets the developer demo the feature without waiting for GA. After the demo, the store can be archived or reused for the next demo.

Partner dashboard organization

Partners accumulate dev stores over time. Organization tips:

• Naming convention: prefix with client name or project code ("clientname-dev", "internal-tool-sandbox")
• Dev store tagging (where Partners dashboard supports): group by client, project, or status
• Cleanup routine: archive or delete stores after 6-12 months of inactivity
• Shared access for team members on active projects via the Partners dashboard's access controls

Without discipline, Partners dashboards end up with 50+ zombie stores, and active ones get lost.

Development store limitations

Dev stores aren't full Shopify:

• Real transactions can't process (checkout is test-mode only)
• Apps from the App Store can be installed at no cost for testing
• Store-to-merchant transfer is a one-way door (once transferred, it's on the merchant's paid plan)
• Some features are region-locked based on the Partner's dashboard country

For testing anything involving real payment processing (one-click pay, wallet payments), a Bogus Gateway or test Shopify Payments mode suffices. For testing production-volume transactions, it has to be a paid Shopify store.

Theme development flow

The Shopify CLI workflow on a dev store:

This runs a local dev server that previews theme changes live against the dev store's data. Changes to local theme code appear in the browser preview immediately; changes to theme-editor settings in the admin appear in local too.

For team development, each engineer can have their own dev copy (theme duplicated per developer) so changes don't collide. Final deploy via shopify theme push goes to the dev store's live theme before production migration.

Beta features and risk management

Beta features on dev stores are useful for prototyping but carry risk:

• Beta may not ship to GA on the expected timeline
• Beta APIs can change between beta releases
• A beta feature demo'd to a client sets expectations the GA feature may or may not meet

Demo with caveats:

• "This is beta; final behavior may differ"
• "Shopify's GA timeline is X, subject to change"
• "We'll validate before committing client roadmap to this"

Clients who see a beta demo and assume GA ship next month are setup for disappointment.

Migration considerations at go-live

At the merchant's go-live from dev store to production:

Things that transfer cleanly:

• Theme and theme-editor settings
• Products, collections, pages, navigation
• Metaobject definitions and entries
• Installed apps and their configs
• Customer accounts (if any were created for testing)

Things that need re-configuration:

• Domain and DNS (the dev store's .myshopify.com URL becomes their production URL, but their custom domain needs to be re-pointed)
• Payment gateway (dev stores use Bogus; production needs real)
• Email templates that referenced dev-specific URLs
• Third-party integrations authenticated via OAuth (tokens tied to dev-store identity)

The go-live runbook covers all of the above. Surprise items on go-live day mean the runbook was incomplete.

What ships with good dev-store discipline

An agency's Shopify dev store setup has:

• Clear distinction between client-handoff and internal-only stores
• Client stores created with "Create a store for a client" flag
• Dummy data selected to match client's vertical
• Theme code in version control from day one, not just in the dev store
• Named environments (dev, staging if needed, production)
• Go-live runbook prepared before the transfer window
• Post-transfer monitoring for the first 48 hours

Dev stores are the first product clients see. Getting them organized makes every subsequent client engagement smoother.