White-Label Shopify Development: How to Vet a Partner Before You Hand Over a Client Store

Generic outsourcing checklists cover NDAs and time zones. This one covers the Shopify mechanics that decide whether a white-label partnership protects your client relationship: who requests store access, who owns the build, where the code lives, and who can handle checkout work after the August 2026 cutoff.

Yuval Tsabari עודכן ב- 16 באוק׳ 2026

Hiring a white-label Shopify development partner solves a capacity problem. It can also create a control problem. The risk isn't only whether the partner writes good Liquid. It's whose name your client sees in their Shopify admin, who owns the store while it's being built, where the code lives, and who can be held accountable when checkout tracking breaks.

Most "how to choose a white-label partner" checklists cover NDAs, time zones, and portfolios. Those matter, but they apply to any outsourced work. This guide covers the Shopify-specific mechanics that decide whether a white-label partnership protects your client relationship or quietly exposes it.

Short answer: Before you hand a client store to a white-label Shopify partner, confirm seven things. (1) Which Partner organization requests store access, and what your client will see. (2) Which permissions the partner needs, and how access is removed. (3) Whose organization owns a new build until it's transferred. (4) That theme code lives in a repository your agency controls. (5) That the partner can work with checkout extensions and pixels now that the August 26, 2026 cutoff for non-Plus stores has passed. (6) A written QA and release process. (7) Commercial terms: confidentiality, non-solicitation, scope, and response times.

1. Decide whose name appears in your client's admin

This is the question generic checklists miss, and it's the one most likely to surprise a client.

On Shopify, outside developers normally get into a merchant's store through a collaborator account. The Partner sends a request with the store's 4-digit collaborator request code, and the merchant approves it. According to Shopify's Help Center, the merchant may see details about the requesting partner on that request, including when the Partner account was created, an approximate range of active collaborations, the country it signed up from, and the country the request was sent from.

So if your white-label partner requests access from its own Partner organization, your client is approving the partner, not your agency.

The cleaner setup is usually the reverse. Shopify Partner organizations use roles, and the Collaborator access role lets a member of your organization log in to assigned collaborator stores. That role can be scoped to specific collaborator relationships instead of every client you have. Requests then come from your agency's organization, and the merchant still controls store-level permissions.

Don't confuse that with invisibility. Individual names still show up in places:

Shopify notes that a removed collaborator's name and actions stay in timelines such as the store activity log and order timeline.
If the theme is connected to GitHub, Shopify's automatic commits name the person who last edited the theme.

The practical move is to decide your disclosure policy first (many agencies name subcontractors in their client contracts), then make the access setup match it. What you want to avoid is a client discovering an unfamiliar company in their admin with no context.

Ask the partner: "Which Partner organization will request access to my client's store? Will your developers join our organization, and where else could your team's names appear?"

What to agree on access and client communication

Whichever organization sends the request, agree on a few access basics before work starts:

Individual access: each developer gets their own assigned access, with permissions appropriate to the agreed scope. Avoid shared logins and shared passwords.
Account ownership: clarify who owns each account, app, and third-party login created during the project.
Access removal: agree how and when access is removed at handover.

On communication, the agency should remain the primary owner of the client relationship. Any direct communication between the partner and the agency's client should follow the arrangement agreed with the agency. Put that arrangement in writing so both sides know when, if ever, the partner speaks to the client and under whose name.

2. Grant the least access that gets the job done, and plan the offboarding

Shopify gives merchants fine-grained control here, but it doesn't make the decision for them. The Help Center is direct about it: collaborators can request, and be given, all available permissions in a store, so the merchant should carefully consider which ones a collaborator needs.

A few platform rules worth knowing before kickoff:

Two-step authentication is mandatory. Partners must turn it on to use a collaborator account.
Access expires on its own. If a collaborator doesn't log in for 90 days, their access expires automatically and has to be reactivated.
Removal is permanent. Once a collaborator account is removed, the Partner has to send a new request to get back in.
Request codes can be rotated. Generating a new collaborator request code makes old codes stop working.
Some things are off-limits. Collaborators can't use Shopify POS, can't be given the Administrator store role on a single store, and can't receive store ownership.

Shopify's guidance on working on client stores recommends collaborator accounts over staff accounts. A staff account is for tasks a collaborator account can't handle, and collaborators don't count toward the store's user limit.

Ask the partner: "For this scope, which permissions do you need, and why?" A good partner can map each permission to a task. "Just give us everything" is a warning sign.

Offboarding checklist: remove collaborator accounts when the work ends, rotate the request code if it was shared widely, revoke repository access, and transfer any app or third-party accounts the partner created during the project.

3. Settle who owns a new build before it starts

For a new store, ownership is set by where the store is created. Shopify's client transfer stores are built by a Partner organization and then handed to the merchant. Per Shopify's developer docs:

The organization that creates the store owns and configures it during the build.
The store name you enter sets its myshopify.com URL, and it can't be changed after creation.
The transfer is sent to the client's email, and pending transfers expire after seven days if they aren't accepted.
After the transfer, the merchant owns the store, and the creating organization keeps collaborator access by default.
Dev stores, which are meant for app and theme testing, can't be transferred to clients.

One more detail from Shopify's Help Center on Partner roles: the Partner team member who creates a client transfer store is its store owner until the store is transferred, and some actions, including transferring ownership, are reserved for the store owner. That's a good reason to have someone from your agency create the store, not the partner's developer.

If the white-label partner creates the client's store in its own organization, the partner controls the handoff. For most agencies, the client transfer store should be created in the agency's organization, with the partner working inside it.

For existing stores the client already owns, there's nothing to transfer. Shopify's collaborations documentation is clear that a collaboration store belongs to the merchant, and the collaborator works only within the permissions the merchant grants.

Ask the partner: "Will you build in a client transfer store created under our Partner organization? Who triggers the transfer, and when?"

4. Keep the code where your agency can see it

A white-label partner who works only in the Shopify code editor leaves you with no history, no review step, and no easy way to switch partners later.

Shopify's GitHub integration for themes syncs a theme with a repository branch. Some details matter for agency work:

Edits made in the Shopify admin (theme editor, code editor, and theme apps) are committed back to the connected branch automatically, so the branch and the theme stay in sync.
The code editor has no conflict alerts. Shopify notes that the code editor's version of a file overwrites the GitHub version.
GitHub outside collaborators can't connect branches. Only members of the GitHub organization with write access can.

That last point affects setup: if the repository lives in your agency's GitHub organization, the partner's developers need to be organization members with write access to connect themes.

It's also worth asking whether the partner runs Theme Check, Shopify's linter for Liquid and JSON in themes. It flags syntax errors, missing templates, deprecated tags, and some performance issues, and it can run through Shopify CLI in continuous integration.

Ask the partner: "Will the repository live in our GitHub organization? How do you use branches, unpublished themes, and pull requests? Do you lint with Theme Check before merging?"

5. Test checkout and tracking skills, not just theme skills

This is the time-sensitive part. According to Shopify's Help Center, August 26, 2026 was the deadline for stores to upgrade and replace their Thank you and Order status pages, and stores that weren't upgraded by then were upgraded automatically. Customizations that relied on incompatible apps, scripts, or pixels now need supported replacements.

For agencies, that means your clients' purchase tracking and post-purchase customizations now depend on newer surfaces: checkout and accounts editor settings, app blocks and extensions, and pixels. Shopify's own documentation on custom pixels calls them an advanced feature that requires JavaScript knowledge and is unsupported by Shopify. They run in a sandbox where not all pixel functionality works. In practice, someone on your team or your partner's has to own building and testing them.

One editorial caution, because it comes up in client conversations: if a client's reported conversions shifted around late August, that's an observation, not a diagnosis. The change could come from tracking, traffic mix, seasonality, or the store itself. A good partner checks the tracking setup with a real test order before anyone draws conclusions.

Ask the partner: "Walk me through how you'd replace a purchase-tracking script that used to live on the Thank you page, and how you'd verify it with a test order."

6. Ask for the QA and release process in writing

Every partner says they test. Ask what that means on Shopify specifically:

Work is built and reviewed on an unpublished theme, not on the live theme.
The main buying paths (search, collection, product page, cart, checkout) are tested on real mobile devices as well as desktop.
Test orders cover discounts, shipping rates, and the payment methods the store actually uses.
Speed is re-checked with the apps the store really runs. Our guide to Shopify speed and UX fixes covers the usual culprits.
Each release has notes your account team can forward to the client under your brand.

For bigger projects such as a WooCommerce to Shopify migration, also ask how the partner handles URL mapping, redirects, and post-launch monitoring.

A release process worth agreeing in writing

A workable QA and release process usually covers these steps:

Document the scope and the acceptance criteria before work begins.
Develop in a preview or unpublished theme where applicable.
Check key functionality and the purchase journey on both desktop and mobile.
Give the agency a review link before anything goes live.
Get sign-off from the designated approver before release.
After release, verify the functionality the change affected.

Each release also needs a rollback plan appropriate to the change. Not every Shopify change can be isolated in a theme. App settings, checkout configuration, and data changes, for example, may need their own way back, so agree on it before the change ships.

Who is responsible for which QA checks, who owns the release, and who approves it are details to agree for each engagement.

7. Cover the commercial basics

These are the items most checklists already cover. They're still non-negotiable:

Confidentiality and non-solicitation: a written agreement that the partner won't contact or pitch your clients. Have your own lawyer review it.
Client contact rules: whether the partner ever joins client calls, and under whose name.
Scope and change requests: what's included, and how extra work is quoted and approved.
Response windows and time zone overlap: especially for launch days and urgent checkout issues.
A paid pilot: a small, well-defined task on a real store is a better test than a portfolio.

White-label Shopify partner checklist

Question	What a good answer includes
Which Partner organization requests store access?	Yours, with the partner's developers on scoped Collaborator access roles, or a disclosure policy your client has agreed to.
What permissions do you need?	A list tied to the scope, not "everything."
Who creates new client stores?	A client transfer store in your organization.
Where does the code live?	A repository in your GitHub organization, with branches connected to unpublished themes.
How do you handle checkout and pixels?	A clear method for extensions and pixels, verified with test orders.
What's your QA process?	Written steps: unpublished theme, real devices, test orders, release notes.
How does offboarding work?	Collaborator removal, code rotation, repository access revoked, accounts handed over.

FAQ

What is white-label Shopify development?

It's when a specialist team builds, migrates, or maintains Shopify stores for an agency's clients, while the agency stays client-facing and delivers the work under its own brand.

Will my client know I'm using a white-label partner?

That depends on how access is set up and what your contract says. A collaborator request from the partner's own Partner organization can show that partner's details to your client. Individual names can also appear in the store's activity log and in theme commit messages. Decide your disclosure policy first, then configure access to match it.

Should a white-label partner use a staff account or a collaborator account?

Shopify recommends collaborator accounts for working on client stores. They give access only to the areas the merchant approves, and they don't count toward the store's user limit. A staff account is meant for the few tasks a collaborator account can't do.

What happens to the partner's access after launch?

Collaborator access stays until the merchant removes it, or until it expires automatically after 90 days without a login. After a client transfer store is transferred, the organization that created it keeps collaborator access by default. Put removal on your launch checklist if the partner's work is finished.

Looking for a white-label Shopify partner?

Dominatecom, a Shopify Select Partner, works behind agencies on Shopify development, from custom builds and migrations to ongoing development, with the same focus we bring to our own clients: understanding the business and improving the buying experience through UX/UI design and CRO.

Engagements can be project-based or ongoing. Terms such as confidentiality, portfolio permissions, subcontracting, response times, support coverage, and working-hour overlap are agreed as part of each engagement, so we can discuss what your agency and your clients need.

Talk to us about white-label Shopify development →