Website Vendor Due Diligence: Team, Code and Delivery

Direct answer：A verifiable method to assess website vendors on team authenticity, code ownership, delivery reliability, and exit readiness.

Core Verification Criteria

Team and Case Validation

Direct team interview: Require a video call with the actual developers and designers who will handle your project, not just sales representatives.
Case evidence: Demand screenshots of Git commit logs, Jira tickets, or design files with timestamps matching the claimed delivery period.
Reference check: Contact two past clients from the last 6 months; ask specifically about team consistency during their project.

Code and Delivery Audit

Repository access: Before final payment, inspect the Git repository for:
Commit frequency (minimum 3x/week for active projects)
Author emails matching vendor domain
Absence of bulk copied code from Stack Overflow (search for "TODO" or "FIXME" comments)
Third-party disclosure: Vendor must provide a signed list of all external libraries, plugins, and APIs with:
License types (GPL dependencies may force open-sourcing your site)
End-of-life dates for critical components
Staging handover: Verify the staging environment includes:
Full database dump
Environment variable documentation
CI/CD pipeline configuration

Red Flags (Automatic Disqualification)

Refusal to show unedited screen recordings of their development environment
Case studies where all commit messages are in a single developer’s name

Acceptance Testing Protocol

Load test: Deploy the delivered code on a clean $5/month VPS; it should install with fewer than 5 manual steps.
Ownership transfer: Successfully push a dummy commit to their repository using provided credentials.
Content migration: Import a 10,000-page CSV export into their CMS without schema errors.

Verification Steps and Records

Team and Case Validation

Request Team Roster: Obtain a current list of team members with roles and LinkedIn profiles.
Case Involvement Proof: Ask for commit logs, project management tool access, or signed statements from past clients confirming individual contributions.
Third-Party Audit: Engage a neutral third-party to verify team claims against public records or past project documentation.

Code and Delivery Review

Code Ownership: Require a full repository access or escrow agreement detailing ownership transfer clauses.
Third-Party Components: List all licensed components with version numbers, licenses, and renewal terms.
Delivery Method: Document the deployment process, including staging environments, rollback procedures, and post-launch support windows.

Acceptance Criteria

Red Flags: Disqualify vendors who refuse to provide verifiable team records or use unlicensed third-party code.
Testing Records: Require at least three documented test cycles with bug resolution metrics.
Exit Handover: Contract must specify data formats, training hours, and knowledge transfer milestones.

Exceptions

Legacy systems may have undocumented components; require a remediation plan.
Offshore teams must provide local legal entity details for contract enforcement.

Evidence Sources and Quality Gates

Team Verification

*Evidence*: Request signed NDAs, then validate full-time employee count via payroll records (redact sensitive data). Case study contributors must match LinkedIn profiles with project timelines.
*Red Flag*: Offshore subcontractors not disclosed in the contract.

Code Audit

*Fields to Inspect*: Repository commit history (last 6 months), third-party dependency licenses, and custom module documentation.
*Acceptance Test*: Run npm audit or equivalent to check unpatched vulnerabilities in dependencies.

Delivery and Handover

*Verification Item*: Demand proof of a recent client handover including DNS transfer records and admin credential rotation logs.

Vendor Exit and Acceptance Criteria

Define contractual exceptions, acceptance tests, and exit paths before signing. Residual decision questions include:

Delivery Verification

Request signed deployment records showing:
Server access logs with timestamps
Pre-launch performance benchmarks
Post-deployment monitoring configuration
Require testing protocols covering:
Cross-browser/device matrices
Core Web Vital baselines
Third-party script impact analysis

Exit Preparedness

Validate handover documentation contains:
Admin credential rotation procedures
License transfer agreements for proprietary components
Archived communication channels (Slack/email threads)
Confirm operations runbooks include:
Incident escalation trees
Backup restoration workflows
Dependency update schedules

Red Flags

No code repository transfer process
Missing infrastructure diagrams
Unverified team retention clauses

Use a weighted scoring matrix (see artifact) comparing:

Legal ownership transfer speed
Knowledge transfer completeness
Post-exit support duration

Verifying Vendor Credentials

Team and Case Involvement

Request Team Profiles: Obtain detailed resumes or LinkedIn profiles of key team members.
Case Studies: Review specific examples of past projects, focusing on roles and contributions.

Code Ownership and Third-Party Components

Code Audit: Ensure the vendor provides full access to the source code.
Third-Party Components: Identify any third-party software used and verify its licensing.

Delivery and Testing

Delivery Method: Confirm the method of delivery (e.g., direct upload, Git repository).
Testing Records: Request detailed logs of testing phases and results.

Operations and Exit Strategy

Operational Capability: Assess the vendor’s ability to handle ongoing site maintenance.
Exit Handover: Ensure there is a clear plan for transferring ownership and operational knowledge.

Decision Criteria

Disqualifying Red Flags: Lack of transparency in team credentials, incomplete code ownership, or inadequate testing records.
Acceptance Checks: Successful completion of a same-sample test project, verified team involvement, and clear exit terms.

Exceptions and Verification Items

Exceptions: Temporary use of third-party components under valid licenses.
Verification Items: Independent verification of team credentials and case study authenticity.

Limited Rollout Evaluation Framework

A controlled pilot project is the most reliable method to assess a vendor’s claims. Define a non-critical but representative scope (e.g., 3-5 page templates with core functionality) with these verification layers:

Baseline Requirements

Team Validation: Require named leads (technical, design, PM) with:
Direct access to commit histories in a shared repository
Recorded kickoff and review meetings (not sales reps)
Code Provenance: Initial delivery must include:
Linting and dependency audit reports (Snyk, SonarQube)
Documentation of third-party licenses (CMS, plugins, fonts)
Build toolchain configuration (not just compiled assets)

Observation Records

Track these metrics daily in a shared log:

Communication Latency: Time to respond to critical path blockers
Change Traceability: Git commits linked to specific Jira/GitHub tickets
Environment Parity: Staging vs. production dependency versions
Defect Resolution: Mean time to acknowledge vs. fix severity-1 issues

Decision Criteria

Proceed only if all red flags are absent:

Team: Subcontractors without NDA coverage
Code: Obfuscated/minified source without maps
Delivery: Manual SFTP transfers without CI/CD logs
Testing: No browser/OS matrix beyond vendor demos

Acceptance Methods

Artifact Review: Compare their case study repos against your pilot branch
Legal Audit: Have counsel verify IP clauses cover all dependencies
Stress Test: Simulate a 30-day termination notice; validate knowledge transfer

Exceptions

Tolerate only if mitigated:

Legacy Systems: Required proprietary plugins with escrowed source
Emergencies: Documented hotfix process bypassing staging

Execution Checklist for Vendor Verification

Team and Case Validation

Direct Team Confirmation: Require video calls with developers, designers, and project managers listed in the proposal. Cross-check LinkedIn profiles and GitHub contributions.
Case Involvement Proof: Demand commit logs, design files (Figma/Adobe XD), and deployment records from past projects. Reject aggregated portfolio screenshots without traceable individual contributions.

Code and Component Audit

Ownership Verification: Review repository transfer logs and copyright headers. Flag projects where core functionality relies on unlicensed third-party plugins.
Dependency Disclosure: Obtain a complete package.json or composer.json with version pins. Critical red flag: undisclosed SaaS dependencies requiring ongoing vendor access.

Delivery and Exit Testing

Staged Handover: Insist on parallel deployment to your AWS/GCP account during UAT. Reject vendors who only provide final FTP transfers.
Runbook Review: Validate documented procedures for cache purging, CDN updates, and database migrations. Test with your team executing 3 critical operations.

Acceptance Criteria:

All production credentials rotated post-handover
72-hour bug resolution SLA for critical issues
Full schema.org markup ownership confirmed

Core Verification Areas

Team and Case Involvement

Evidence Required: Request signed NDAs to access:
Team member LinkedIn profiles matching contract roles
Commit logs showing named contributors (not generic "[email protected]")
Case study screenshots with verifiable client domains redacted but metadata intact
Red Flags:
Refusal to provide commit access to version control during development
Case studies with identical timestamps or boilerplate text

Code Ownership and Third-Party Components

Audit Steps:

Review package.json/composer.json for:

Unmaintained libraries (last update >2 years)
GPL dependencies requiring disclosure

Demand a bill of materials for:

CMS core modifications
Licensed plugins/themes with purchase receipts
Acceptance Criteria:

No GPL contamination in proprietary modules

Delivery and Handover Testing

Verification Method:
Require video recordings of:
Staging environment smoke tests
Database migration dry-runs
Validate via:
Checksums against delivered artifacts
wp-cli/drush output showing config export completeness
Critical Gaps:
Missing rollback scripts for CMS updates
No documented procedure for credential rotation

Operational Continuity Controls

Checklist:
[ ] Hosting architecture diagram showing:
Isolated production/staging environments
Backup storage location and encryption method
[ ] Runbook with:
Minimum 3 emergency contacts
Escalation paths for after-hours outages

Exception Handling

For agencies using proprietary platforms:

Demand escrow agreement covering:

Source code
Environment provisioning templates
Training materials

Verify escrow agent tests:

Annual restoration drills
Legal jurisdiction for enforcement

admin