You've picked your developer and the first task is waiting. The next 30 days decide whether this becomes a safe, well-run engagement or a mess of shared passwords, missing code and an ex-freelancer who still has store access a year later.
This checklist starts after you've chosen someone. If you're still comparing candidates, use our vetting checklist first. Here we cover access, security, the theme and app workflow, the first month, and offboarding.
Pick the right kind of access
Shopify gives you several ways to let someone work on your store. None of them require sharing your own login.
| Access type | Use it for | Good to know |
|---|---|---|
| Your owner login | Nobody but you | Never share it. There's always a better option below. |
| Collaborator account | Freelancers and agencies with a Shopify Partner account | Doesn't count toward your user limit. The Partner must have two-step authentication turned on, or they can't log in. |
| Staff account | Someone working inside your company | Counts toward your plan's user limit: 0 on Starter and Basic, 5 on Grow, 15 on Advanced, unlimited on Shopify Plus. |
| App developer role | A developer building custom apps in your organization's Dev Dashboard | Gives Dev Dashboard access but no access to production stores or financial and billing information. |
| Theme Access password | Theme work through Shopify CLI when the person has no staff or collaborator account | Grants only the write_themes scope. You revoke it by deleting the password. |
For most outside developers, use a collaborator account. It uses no seat, requires two-step authentication, and can never be given the Administrator role on a single store, the POS app, or ownership of your store.
How to give a developer access to your Shopify store (step by step)
For a freelancer or agency with a Shopify Partner account, the collaborator request is the safe route. It takes a few minutes:
- In your Shopify admin, go to Settings > Users > Security and copy your 4-digit collaborator request code. Send it to the developer privately.
- The developer requests access from their Dev Dashboard, using your permanent
myshopify.comaddress (custom domains don't work) and your code. They choose the permissions they're asking for. - The request appears on the Users page of your admin. Open it and check the details Shopify shows, such as when the Partner account was created and its sign-up country. If anything looks off, ask before accepting.
- Shopify suggests a role named
<Collaborator name>x<Store name>. Edit its permissions down to what the work needs (see the table below), or assign an existing role, then accept. - After access is granted, click Generate new code so the old code can't be reused.
Two things to know. First, if the developer's organization already has an app installed on your store, Shopify doesn't ask them for a request code at all. Second, collaborators can request every permission in your store, and store permissions apply to the whole store. You can't limit a collaborator to certain orders or customers. The role you approve is the only real boundary.
If the developer has no Partner account and only needs to push theme code with Shopify CLI, create a Theme Access password for them instead. If they work inside your company, add them as a staff account with a role limited to their work.
Day 0: set up access before the first task
Which permissions to grant for which job
| Type of work | Grant | Leave off unless there's a clear reason |
|---|---|---|
| Theme work (sections, templates, speed) | Online Store > Themes, Edit code if they edit code in the admin, plus view access to the products or content the templates show | Customers, Orders, Finance, payment settings |
| App or integration work | Apps and channels > Manage and install apps and channels, plus view access to the data the integration touches (products, orders, inventory) | Customers > Request data, Export, Finance |
| Checkout and Thank you page work | Checkout and customer accounts > View and edit, plus Apps and channels to install the app that holds the extensions | Payment settings, billing |
| Never for a developer | Manage payments settings, Manage other payment settings, Edit billing payment methods and pay invoices, View tax documents, Customers > Request data |
Shopify labels every permission in that last row as sensitive, for good reason: they reach banking, payment and personal customer data. A developer building a theme section has no use for them. If someone asks for a permission you don't understand, ask them why. That's Shopify's own advice too.
Day 0 checklist
| Item | Done when |
|---|---|
| Collaborator request accepted with a trimmed role | The role only contains the permissions from the table above |
| Request code regenerated | The old code no longer works |
| Two-step authentication | Shopify requires it for every collaborator. For staff accounts, set Secure sign-in method is required on each user under Settings > Users |
| Git repository in your GitHub organization | The developer is an organization member with write access, not an outside collaborator |
| Backup of the live theme | You duplicated the published theme and noted the date |
| Access register | A shared document lists every account, role, password and token the developer has, with the date granted |
| Secrets channel agreed | Credentials go through a password manager, never through chat or email |
| Analytics and ad accounts | The developer is invited with their own login and a limited role (see below) |
Set up the theme workflow before any code changes
The rule: nobody edits the live theme directly. Shopify gives you two tools for this.
The GitHub integration. Shopify can connect a GitHub branch to a theme and keep the two in sync both ways: a push to the branch updates the theme, and edits saved in the theme editor or code editor are committed back to the branch, usually within about 10 seconds. We connect the main branch to the published theme, so the live store always matches main, and do feature work on other branches connected to unpublished themes.
Three details catch people out:
- Outside collaborators can't connect branches. Only members of the GitHub organization with write access can. Add your developer as a member, or connect branches yourself.
- A disconnected branch can't be reconnected to the same theme. Reconnecting it creates a new theme.
- Merchant edits become commits. When your team changes settings in the theme editor, those changes land in the branch. Your developer should pull before starting work.
Shopify CLI development themes. For day-to-day work, the developer runs shopify theme dev. This creates a hidden development theme with a local preview that reloads as they save. Development themes don't count toward your theme limit and are deleted after seven days of inactivity, or when the developer logs out of the CLI. To give you a preview link that lasts, they push to an unpublished theme:
# Local preview against your store (needs the Themes permission)
shopify theme dev --store your-store.myshopify.com
# Share a preview that survives logout: create an unpublished theme
shopify theme push --unpublished --store your-store.myshopify.com
# Pull merchant edits from a theme before starting new work
shopify theme pull --theme "Live theme name" --store your-store.myshopify.com
A collaborator needs the Themes permission to run these commands. If you'd rather not create an account at all, a Theme Access password works with the --password flag. Shopify emails the developer a link to it that expires after seven days or after one viewing.
Decide who owns apps before one is built
New custom apps are built in the Dev Dashboard, not the Shopify admin (custom vs public apps explained). Collaborators can't access the Dev Dashboard, because they have no organization-level permissions. That leaves two setups:
| Setup | How it works | Trade-off |
|---|---|---|
| App in your organization (our default recommendation) | Your organization owner or an organization administrator gives the developer the App developer role. They build the app in your Dev Dashboard. | You own the app and its credentials from day one. The role can't reach production stores, so they still need a collaborator account for store work. |
| App in the developer's organization | They build it in their Dev Dashboard with custom distribution, and you install it from a link. | Quicker to start, but the app, its client secret and its settings live in someone else's account. |
If you go with the second setup, put the exit plan in writing now: the source code lives in your repository, and the developer will help recreate and reinstall the app under your organization if you part ways. We found no documented self-serve way to move an existing app from one organization to another, so don't count on one.
API credentials hygiene
- Never paste admin tokens or client secrets into chat, email or tickets. Share them through a password manager and keep them out of the repository.
- Keep scopes narrow. Ask what each requested access scope is for. An integration that only reads inventory doesn't need write access to orders.
- Rotate when it matters. Shopify recommends rotating a Dev Dashboard app's client secret if it's been exposed, if someone with access has left, and as regular hygiene. You rotate it under Dev Dashboard > Apps > your app > Settings > Credentials.
- Rotate in order. Shopify signs webhooks with the app's oldest unrevoked secret, so the app must accept both secrets during the switch. Replace the access tokens, then revoke the old secret. Any token still tied to it stops working.
- Legacy admin-created custom apps have no secret to rotate. To change their credentials, you uninstall and reinstall the app, which issues a new token.
If you use the Admin API heavily, also read our guide to expiring offline access tokens.
Third-party tools: roles, not shared passwords
Your developer will often need Google Analytics 4, Google Ads or Meta to check tracking. Invite their own login with the lowest role that covers the task.
In GA4, the predefined roles are Administrator, Editor, Marketer, Analyst and Viewer. A developer checking that events arrive usually needs Viewer or Analyst. One who configures events and key events needs Marketer or Editor. Only you should hold Administrator, because it can manage users. You can also apply the No Cost Metrics and No Revenue Metrics data restrictions if the developer doesn't need to see those figures.
Do the same in Google Ads and your Meta business portfolio: give access to the specific assets needed, such as the pixel or ad account, never a shared login. If your tracking runs through Customer Events pixels (why that changed), record who installed each one.
Week 1: a small first task and a definition of done
Start with something real, small and easy to roll back. For example:
- fix one layout bug on a single template, on an unpublished theme
- add one section with settings your team can edit in the theme editor
- write a read-only script that lists products missing a metafield
The point is to test the whole loop (access, branch, preview, review, release) before anything risky depends on it.
Definition of done
Agree on this in writing before the first task:
| Check | What you should see |
|---|---|
| Preview | A preview link on an unpublished or development theme, tested on mobile and desktop |
| Code review | A pull request into your repository, reviewed by you or a second developer before merging |
| No secrets in code | No tokens, passwords or client secrets anywhere in the diff or commit history |
| Editable where it should be | Text, images and colors your team changes often are theme editor settings, not hard-coded |
| Checkout changes tested | A test order placed for anything touching cart, checkout or the Thank you page |
| Rollback | You know which theme or commit to go back to if something breaks |
| Notes | A short entry in the project documentation: what changed and why |
Week 1 checklist
| Item | Done when |
|---|---|
| First task shipped | Merged, released and checked on the live store |
| Review loop tested | At least one pull request was commented on, fixed and approved |
| Communication set | One task board, one channel, agreed overlap hours |
| Access confirmed | The work got done with the permissions granted, and nothing extra was requested without a reason |
Weeks 2–4: cadence and documentation
By week two, the work should run without you chasing it.
| Area | What good looks like |
|---|---|
| Cadence | A short written update (daily or weekly): shipped, next, blocked. A preview or demo each week. |
| Backlog | Tasks have acceptance criteria and are prioritized by you |
| Documentation | A README in the repository covering how to run the theme or app locally, where each custom feature lives, and the names (never the values) of environment variables |
| Integration notes | For every app or integration: its scopes, webhooks, API version and who owns its credentials |
| Platform changes | Shopify deadlines that affect your store, such as API version upgrades, are flagged early |
Day 30 review
- Filter Settings > Users by collaborators and confirm each account still needs access.
- Remove permissions the work hasn't used, and update the access register.
- Agree on the next month, or end the engagement cleanly.
Offboarding: close every door
Don't rely on Shopify's automatic expiry. Collaborator access only lapses after 90 days without a login, and it can be reactivated. When the work ends, work through this list on the same day:
| Step | Where |
|---|---|
| Remove the collaborator account | Settings > Users > select the collaborator > Remove collaborator account. This is permanent. |
| Remove staff accounts or the App developer role | Settings > Users, or your organization's user settings |
| Delete Theme Access passwords | The Theme Access app |
| Rotate client secrets of any app they could see | Dev Dashboard > your app > Settings > Credentials, then revoke the old secret once tokens are replaced |
| Reset legacy custom app tokens | Uninstall and reinstall the app |
| Remove them from GitHub | Remove them from your organization. Transfer any repository they created under their own account to yours. |
| Remove analytics and ad access | GA4, Google Ads, Meta and any other tool from your access register |
| Regenerate the collaborator request code | Settings > Users > Security > Generate new code |
| Review installed apps | Uninstall apps from their organization, or rebuild them in yours first |
| Collect the handover | Documentation and open tasks, checked against the access register |
Red flags during onboarding
- Requests for payment, billing or customer-data permissions without a clear reason.
- Tokens or passwords sent over chat.
- Pushing straight to the live theme, or refusing to work in your repository.
- A collaborator request you weren't expecting, or from a name you don't recognize. Shopify's advice is not to accept it.
Want help with a dedicated Shopify developer?
Our dedicated Shopify developers work this way from day one: trimmed collaborator roles, code in your repository, apps in your organization, and a clean offboarding. See how to hire a dedicated Shopify developer from our team.
Sources
- Shopify Help Center: Collaborator accounts
- Shopify: Collaborations in the Dev Dashboard
- Shopify Help Center: Maximum number of users for each pricing plan
- Shopify Help Center: Store-level permissions
- Shopify Help Center: Two-step authentication for users
- Shopify Help Center: Roles managed by Shopify
- Shopify Help Center: About custom apps
- Shopify: GitHub integration for themes
- Shopify: Shopify CLI for themes
- Shopify: Theme Access app
- Shopify: Rotate or revoke client credentials
- Google Analytics Help: Access and data-restriction management
