Evaluate the supplier against your actual requirements: relevant contribution, demonstrated editor workflow, named delivery responsibility and a usable handover. Keep evidence confidence separate from capability ratings. Resolve store control, source access, third-party licensing and support obligations before treating a high score as a hiring decision.
A live store link can show attractive work without proving who built the part you need. A detailed confidential walkthrough can be more relevant, provided the supplier can explain its contribution and share the material with permission.
I would prepare the requirement first and evaluate evidence against it. This guide uses the fictional R-CAM-01 campaign requirement from the development-brief exercise. The suppliers and scores below are illustrative, not real evaluations or CartCompound service claims.
Put it into practice
Store build decision pack
Turn a store requirement into comparable route evidence, explicit ownership and a cost model you can challenge.
Explore this resourceChoose the team structure from the work
List the work your project requires: theme implementation, product-data modeling, app integration, visual design, content approval, testing, editor training and support. Identify who coordinates dependencies and who can make decisions. A solo developer and an agency can each fit some requirements; the title alone does not establish coverage.
Ask who will actually deliver each requirement, who reviews their work, whether subcontractors are involved and who remains available after handover. For a narrow section task, avoid buying a vague full-service promise. For an integration with uncertain behavior, establish discovery responsibility before comparing implementation commitments.
The Shopify Partner Directory offers service, location, language and USD price filters, and contacting a Partner does not commit you to hiring. Use that to find candidates; then evaluate the specific work and people. Shopify explains the directory process.
Ask what the example proves and who contributed
Attach evidence to requirement IDs. For R-CAM-01, an attractive homepage is weak evidence of a safe merchandiser-editable campaign. Ask for the actual section/settings contribution, how product data is connected and how an unrelated page stays unchanged.
| Evidence received | What it can establish | Question still open |
|---|---|---|
| Supplier assertion | What the supplier says it can do | Where is supporting evidence for this requirement? |
| Attributable example | A described contribution with date, scope and role | Does the work match the current requirement? |
| Scoped demonstration | Observed behavior under stated conditions | Who built it, and how does it transfer to this store? |
| Permissioned corroboration | An authorized source confirms specific contribution or delivery | Does that account cover this task, team and period? |
This is a sequence of evidence types, not a universal ranking. A reference may confirm communication without proving a technical feature. A demonstration may establish capability in its environment without proving production reliability. Record those limits.
Ask for permission before contacting a reference or reusing screenshots. Accept redaction and confidential demonstrations when the contribution can still be explained and substantiated. Do not demand unpaid implementation as a portfolio test. If more proof is needed, agree a bounded paid discovery or sample task with clear deliverables.
Keep access approval separate from store ownership
For an existing merchant store, a collaboration is access, not a transfer of ownership. Shopify recommends collaborator access and prohibits using the merchant's password. Collaborators require two-step authentication, do not consume user limits, and their access can be removed. Store ownership cannot be transferred to a collaborator.
Ask for a task-by-task access explanation, the person or organization requesting it, the authorizer and the removal point. Grant only what the approved work requires. Some tasks need an authorized staff-account route rather than a collaborator; verify the need before granting access. Confirm expected requests using a known communication channel.
Request procedures vary by path. Current developer documentation uses Dev Dashboard and documents a separate app-current-installs request flow. Verify the appropriate path rather than assuming every request has the same code steps. This evaluation does not authorize any request or account change.
Separate source delivery, license rights and usable access
“You own everything” is too vague to review. Ask for an asset register that distinguishes original deliverables, third-party products and hosted dependencies. Then document the rights agreed for each, where the editable materials live and what the merchant can actually access.
| Item | Source or access evidence | Rights/dependency question |
|---|---|---|
| Original custom section | Repository/export, current revision, setup notes and configuration | What agreed rights permit use and modification? Any retained components? |
| Paid theme | Theme name, purchase/store record and applicable license | Which store is licensed, and what third-party terms remain? |
| Builder or hosted app content | Merchant-controlled account and export/exit documentation | What remains visible and editable after cancellation or supplier departure? |
| Custom app/integration | Deployment/configuration notes, service owner and access inventory | Who operates hosting, billing, secrets and maintenance? |
| Designs, copy, fonts and images | Editable originals where agreed and asset provenance | Which items need separate permission or licenses? |
A Theme Store purchase licenses that theme to the purchasing store; Plus storefronts need separate licenses. That product rule is different from rights to custom code. A repository login does not by itself settle either question.
Reconcile the proposed route with the promised handover. Current Canvas-edited themes cannot be downloaded and do not receive theme updates. If a proposal promises a downloadable theme ZIP, ask how that promise fits its actual editing route. Avoid assuming one theme export contains every app, asset or hosted dependency. Check the current Canvas limits.
Keep unknown evidence outside the score
- Ask what the evidence proves. Record the supplier’s contribution, relevant conditions and confidence separately from capability.
- Rate only supported criteria. A partial walkthrough does not establish the whole requirement. Unknowns stay unknown.
- Resolve blockers separately. Requirement fit, access/control, custom-source rights, license exceptions and support ownership cannot be averaged away.
Illustrative example Only fictional B’s handover is rated: 35 × 1 against 35 × 2, so 35/70 = 50%. This handover-only subtotal covers 35/100 weight points.
Requirement fit (40) and support (25) leave 65 weight points unknown. The subtotal is not an overall score, pass mark or hiring decision.
Evaluate delivery commitments as evidence, too
Ask for the named delivery owner, milestone outputs, review process and your approval responsibilities. Define how a changed requirement is estimated and approved, how defects differ from enhancements and what happens when a dependency arrives late. Check meeting hours and escalation coverage against the people who will actually be available.
Support needs a route, owner, coverage period, exclusions and commercial terms. Ask who handles an app update that breaks the section and what happens if the original developer is unavailable. Compare one-time fees and recurring dependencies separately, with currency and tax treatment recorded as supplier inputs.
For handover acceptance, have the intended editor complete the agreed campaign task and have the maintenance owner locate the source/configuration record. A presentation of files is useful evidence of delivery; successful authorized use of the agreed workflow answers a different question. The full operational handover plan belongs in the project scope.
Use founder-chosen weights without hiding unknowns
Choose criteria and weights before rating candidates. Suggested criteria are requirement fit, relevant demonstrated capability, delivery responsibility, maintainability/handover and support. Set your own weights to reflect the project. These are decision aids, not industry benchmarks.
For each criterion, record relevance to the requirement, capability rating and evidence confidence separately. One optional capability scale is 0 for demonstrated mismatch, 1 for partial fit and 2 for demonstrated fit. Use unknown when the evidence is insufficient; do not turn it into zero or a guessed middle score. Label confidence low, medium or high with a reason, rather than using confidence to imply technical quality.
If you calculate a weighted subtotal, multiply each known rating by its weight and divide by the maximum weighted score for those known criteria. Report the covered weight next to the subtotal. Do not compare partial subtotals as if they cover the whole project. Keep unresolved rights, unacceptable access, missing critical capability and unsupported handover promises in a separate blocker list. A strong design score cannot cancel them.
Hypothetical worked example
Fictional supplier evidence exercise. R-CAM-01 is the same campaign-editing requirement used in the development-brief guide. These are three fictional profiles, not actual candidates. No reference was contacted, trial commissioned or access granted.
| Supplier | Evidence received | Capability/relevance assessment | Confidence and open decision |
|---|---|---|---|
| A | Public store URL; no contribution statement | R-CAM-01 unknown: appearance does not show editor workflow | Low. Ask which section/settings A built, when and under what scope. Theme-license responsibility unknown. |
| B | Permissioned redacted technical walkthrough and handover sample; client name cannot be disclosed | R-CAM-01 partly relevant: walkthrough shows page-specific editing, but full requirement fit remains unknown until contribution, product-source behavior and unchanged-page evidence are confirmed | Medium confidence in the limited walkthrough evidence. Confirm authorship, environment, product failure case and unchanged unrelated-page behavior. Confidentiality alone is not a capability failure. |
| C | Original section source sample, licensed third-party theme identified and named maintenance owner | Relevant section and maintainability evidence; exact editor acceptance still untested | Medium. Confirm purchasing-store license, agreed custom-code rights and actual availability of named owner. |
Suppose the founder chooses these illustrative weights: requirement fit 40, handover maintainability 35 and support 25. For fictional B, full R-CAM-01 requirement fit remains unknown: the walkthrough does not establish authorship, correct product-source failure behavior or the unchanged unrelated-page case. The founder records 1/2 for handover based on the incomplete sample and unknown for support because no terms were supplied. The limited editing evidence does not justify a rating for the full requirement. These are hypothetical judgments, not measured performance.
Only handover has a known rating. Its weighted contribution is 35 × 1 = 35, against a known maximum of 35 × 2 = 70. The subtotal is 35/70 = 50%, covering 35 of 100 chosen weight points. Requirement fit (40) and support (25) leave 65 weight points unknown. This is a handover-only subtotal, not a 50% overall score, a pass mark or a reason to choose B.
| Question | Current state | Required resolution |
|---|---|---|
| Full R-CAM-01 requirement fit | Unknown; evidence covers only part of the requirement | Confirm contribution and environment, then demonstrate correct product-source failure behavior and unchanged unrelated-page behavior |
| Store access and control | No proposed permission scope supplied | Approved least-needed access plan and merchant control confirmed |
| Custom source rights and license exceptions | Not established by the redacted sample | Reviewable asset/source/right schedule for this engagement |
| Support owner and terms | Unknown | Named owner, route, coverage, exclusions and cost input |
| Downloadable theme promise if Canvas is proposed | Route not supplied | Reconcile promise with current Canvas restrictions before agreement |
A cannot be rejected solely for lacking a public technical walkthrough, but its contribution remains unverified. B cannot be rejected solely for protecting a client name, but confidentiality does not close the remaining evidence gaps. C's source sample does not remove the need for theme licensing or custom-rights clarity. Request requirement-specific clarification, then reassess the evidence without declaring a winner from incomplete information.
Frequently asked questions
Does a Partner listing prove the developer built a portfolio store?
The directory helps find suppliers. For a specific project, ask for contribution, date, scope and permissioned supporting evidence. Do not treat a listing or public URL as proof of the exact work needed.
Must I share my Shopify password?
No. Shopify prohibits using merchant credentials and recommends collaborator access for appropriate tasks. Verify an authorized alternative only when a task cannot use that route.
Does receiving the source mean I own every part of the site?
Source delivery, usable access and agreed rights are separate. Identify original work, third-party themes/assets and hosted dependencies. Theme Store licensing is store-specific; custom-project rights need explicit agreement.
Should I choose the highest weighted score?
Use scores to structure a discussion, not to erase unknowns. Compare evidence coverage and confidence, resolve critical blockers and make the decision against the actual requirement. There is no universal pass mark.
Sources and further reading
- Shopify Help: Hiring and working with Shopify Partners
Source checked: October 31, 2026.
- Shopify Help: Working on client stores
Source checked: October 31, 2026.
- Shopify Help: Collaborator accounts
Source checked: October 31, 2026.
- Shopify developer docs: Collaborations
Source checked: October 31, 2026.
- Shopify Help: Theme licensing and transfer
Source checked: October 31, 2026.
- Shopify Help: Canvas requirements and considerations
Source checked: October 31, 2026.
About the author
Hamid Khan
Hamid co-founded CartCompound and works with ecommerce founders on their stores and growth priorities.
Profile and guides
