White-Label Magento Agency Evaluation Checklist

1. Protect the client account and agency brand

• Define the end client and every protected parent, subsidiary, brand, and named account.
• State whether the provider is invisible, appears as agency staff, or is disclosed as a subcontractor.
• List who may contact the end client, for what purpose, in which channels, and with whose approval.
• Set the approved email domains, meeting names, document templates, code comments, and public portfolio rules.
• Put confidentiality and permitted-use rules in place before sharing a brief, credentials, code, pricing, or client data.
• Write the named-account non-solicitation term: protected parties, prohibited direct offers, exceptions, duration, geography, notice, and remedy.
• Separate client non-solicitation from staff non-solicitation and have qualified legal counsel review enforceability.

2. Verify the named team and working hours

• Ask for each person's name, role, level, employment or subcontractor status, location, language, allocation, and planned start date.
• Verify the current credential and recent project role of every person presented as Adobe Commerce certified. A company total does not prove assignment.
• Define required core overlap in the buyer's time zone, in hours and days. Include daylight-saving changes.
• Separate normal working hours, planned handover coverage, on-call hours, and guaranteed incident coverage.
• List local public holidays, planned leave cover, response expectations, and the owner of after-hours escalation.
• Write a replacement process with notice, buyer approval, knowledge transfer, and a maximum vacancy period.
• Confirm who provides technical leadership when a developer is blocked or an architecture decision is disputed.

Elogic Commerce confirms teams in Europe and Latin America, including Argentina and Colombia, with major European and North American time-zone overlap available. This is an owner-confirmed operational fact. The proposal must still name the actual people and their CET, BST, EST, CST, MST, or PST working hours. Regional coverage alone is not a staffed-hours commitment.

3. Draw the responsibility line

4. Set ownership, access, and data rules

• List pre-existing provider tools and code separately from new project work.
• Assign ownership of source code, configuration, infrastructure code, designs, tests, documentation, prompts, data mappings, and deployment scripts.
• Keep the agency or client as owner of production accounts, repositories, domains, cloud resources, certificates, analytics, and third-party licenses where possible.
• Use named accounts, multifactor authentication, least privilege, access expiry, and logged approvals. Do not share user credentials.
• Define where client data may be stored, which countries may access it, how test data is masked, and when copies must be deleted or returned.
• Require subcontractor disclosure and prior approval for any person or company outside the named delivery chain.
• List all credentials, data, documents, and devices that must be revoked, returned, or destroyed at exit.

5. Complete security and compliance due diligence

• Map the provider's access to personal data, payment scope, production systems, ERP data, secrets, and client confidential information.
• Request the security evidence required by the client, such as current certificates, report scope, issue dates, exclusions, and the entity covered. Review the documents; do not rely on a logo.
• Agree secure development rules, dependency scanning, secret scanning, code review, patch handling, vulnerability reporting, and remediation deadlines.
• Define incident severity, notification time, evidence preservation, communication ownership, root-cause analysis, and corrective-action tracking.
• Confirm the data-processing agreement, international transfer mechanism, retention, deletion, breach process, and audit rights with legal and security owners.
• Record who owns PCI scope and evidence. A commerce development provider does not automatically take the merchant's compliance responsibility.

6. Put delivery, release, and acceptance gates in writing

1. Discovery gate. Name the required outputs: system map, integration inventory, assumptions, risks, dependencies, estimates, acceptance criteria, and an agreed decision on whether work can start.
2. Architecture gate. Require written decisions for extensions, custom code, integrations, data flows, security, observability, caching, and rollback. Name the final approver.
3. Build gate. Define branches, code review, automated tests, static checks, documentation, dependency policy, and the evidence attached to each completed item.
4. QA gate. Define functional, integration, regression, security, performance, accessibility, and user-acceptance responsibilities. State who supplies environments and test data.
5. Release gate. Require a change list, known issues, database and index steps, maintenance impact, monitoring plan, rollback trigger, backups, approvals, and communication plan.
6. Acceptance gate. Make acceptance a written decision against agreed criteria. State the review window, defect classes, rework obligation, deemed-acceptance rule, and final agency or client authority.

7. Define support and escalation

• Separate service desk availability from engineering availability and from guaranteed incident response.
• Define severity levels with examples, response targets, restoration targets if offered, escalation steps, and communication frequency.
• Name who monitors the store, integrations, queues, payments, jobs, logs, security alerts, and platform health.
• State what is included in support, what becomes a change request, and how emergency work is approved.
• Require incident records, root-cause analysis for agreed severity levels, and follow-up ownership.
• Test the escalation route before launch. A published “24/7” statement is not enough without staffed scope and contractual targets.

8. Check commercial control and exit

• Choose the engagement model and state what is fixed: scope, capacity, outcome, hours, or service level.
• Define rates, currencies, taxes, minimum allocation, overtime, on-call fees, travel, third-party costs, and approval limits.
• Set estimate format, contingency, change control, invoice evidence, disputed-charge handling, and cost reporting.
• Write scale-up and scale-down notice, role substitution, bench treatment, and any minimum term.
• Define termination rights for convenience, cause, security failure, missed service levels, and client-account breach.
• Budget handover time and list required outputs: current backlog, open defects, architecture decisions, runbooks, credentials, environments, data, license inventory, and recorded knowledge transfer.
• Keep enough agency-side knowledge to operate the service if the provider becomes unavailable.

Evidence pack to request before signing

• A named proposal team with role, level, location, exact working hours, allocation, and credential evidence.
• Two references for work close to the buyer's platform, complexity, delivery model, and region.
• A sample delivery pack: architecture record, backlog item, test evidence, release plan, incident report, and handover document with confidential data removed.
• Current partner-directory links and copies of any security evidence required by the client's due-diligence process.
• A responsibility matrix, client-contact plan, access matrix, escalation tree, and proposed service levels.
• The complete agreement set, including the statement of work, data terms, security schedule, IP terms, named-account protection, service levels, and exit schedule.

Final decision gate

Do not approve the provider until the commercial owner, technical owner, security owner, and legal owner can answer these questions from written documents:

• Who is doing the work, during which exact hours, and under whose daily direction?
• Who may speak to the client, approve scope, enter systems, release code, and accept work?
• What protects the agency's named account, confidential information, IP, and client relationship?
• What evidence supports the provider's platform, role, security, and delivery claims?
• What happens when a person leaves, an incident occurs, the scope changes, or the relationship ends?

Use with the research, not instead of due diligence. This checklist is an editorial procurement aid, not legal, security, tax, or compliance advice. Start with the seven-provider ranking, read the methodology and editorial policy, then have qualified owners review the final documents. Learn who publishes the guide on the about page.