Outsourcing Team Onboarding Checklist: The 30-Item Framework That Saves Week 4

Direct Answer

The single biggest predictor of whether an outsourcing engagement ships on time is whether onboarding is done in week 1 or whether it slowly leaks across weeks 1-4. A complete 30-item onboarding checklist — covering access provisioning, code-base orientation, decision-making contracts, eval expectations, and escalation paths — turns week 4 from "still waiting on access to staging" into "first production change shipped, eval pass rate measured." This is the cheapest week of an engagement to optimize, and the highest-leverage.

TL;DR

• Most outsourcing engagements lose week 1-3 to slow onboarding. Access waits, code-base discovery, decision-making confusion, escalation ambiguity. By the time real engineering starts, three weeks of project budget is already spent.
• A 30-item onboarding checklist run on day 1 fixes this. Five sections: access (8 items), code-base orientation (6 items), decision-making contracts (5 items), eval expectations (5 items), and escalation paths (6 items).
• The vendor and the buyer share the checklist. It is not a vendor-only or buyer-only artifact. Both sides commit to clearing items by end of day 3.
• Re-run the checklist at week 6. Mid-engagement onboarding gaps (new vendor team member, scope expansion, integration system changes) cause more delivery delays than initial gaps.
• The checklist is a hard prerequisite for Eval Week 1. No data access, no eval set. No eval set, no production-grade engagement.

What You Will Get From This Page

• A complete 30-item onboarding checklist organized into 5 sections.
• The exact responsibility split between vendor and buyer per item.
• A day-by-day timeline for clearing the checklist in the first 3 working days.
• The mid-engagement re-run protocol.
• Three patterns that signal onboarding is broken even when the checklist is "complete."

Why Most Outsourcing Onboardings Take 3 Weeks

Three structural reasons:

1. Onboarding is treated as a shared-responsibility problem with no named owner. The vendor assumes the buyer will provision access. The buyer assumes the vendor will tell them what to provision. Both wait. The default outcome is week 1 lost to nothing happening.

2. Code-base orientation is informal. Vendor engineers spend day 1-3 reading code without a guided tour. They build mental models that may or may not match the buyer's actual mental model. Misalignment surfaces in week 4 as "we built it differently than you wanted."

3. Decision-making contracts are unspoken. Who approves architectural changes mid-sprint? What is "minor scope" vs "change request"? Who calls weekly status? When things blow up, no one knows.

The 30-item checklist below is designed to make all three explicit by end of day 3.

The 30-Item Onboarding Checklist

Section A: Access Provisioning (8 items, owned by buyer)

Day 1 morning, ideally pre-wired before kickoff:

1. Source repository access. Read+write access to the GitHub/GitLab org for every vendor engineer, with named role assignment (admin, write, maintain). Use a vendor-specific team and grant team access, not individual access.
2. Cloud accounts (staging + prod). Console access for tech lead, programmatic access (IAM role + service account) for the engineering team. Enforce MFA. Document the named cost center for any spend incurred.
3. CI/CD pipeline access. Vendor engineers must be able to read build logs and trigger non-prod deployments. Production deploy permission stays with the buyer's named SRE/platform owner.
4. Observability tools. Datadog / Grafana / Sentry / LangSmith — read access for the entire vendor team, write access for the tech lead.
5. Communication channels. Shared Slack / Teams channel with vendor team + named buyer-side liaisons. Set retention to ≥90 days.
6. Document store. Notion / Confluence / SharePoint workspace — vendor team read+write on the engagement-specific workspace, read-only on the broader org workspace.
7. Issue tracker. Linear / Jira / GitHub Projects — vendor team write access on the engagement-specific board.
8. Secrets management. Vendor tech lead gets named-user access to the secrets vault for the engagement-specific scope, with rotation cadence committed to (typically quarterly).

If any of these 8 take more than 24 hours after kickoff, the engagement is starting at a disadvantage. Provision before kickoff if at all possible.

Section B: Code-Base Orientation (6 items, owned jointly)

Day 1 afternoon to day 3:

9. Architecture decision record (ADR) tour. Buyer's senior engineer walks vendor through the top 5 ADRs in 60-90 minutes. If no ADRs exist, this becomes the first one for the engagement.
10. System diagram review. Latest as-built system diagram, even if hand-drawn. Vendor tech lead annotates with questions during the review.
11. Critical-path code review. Buyer points vendor at the 2-3 most load-bearing code paths in the codebase. Vendor reads end-to-end with the buyer's senior engineer answering questions.
12. Failure-mode tour. What has broken in production in the last 6 months? What was the root cause? What changed afterward? This single conversation prevents 70% of "we did not know that was sensitive" mistakes.
13. Eval set introduction (or co-build kickoff). If the buyer has an existing eval set, vendor reads it. If not, vendor and buyer schedule the eval co-build kickoff (Day 3-5). The Eval Week 1 framework covers the methodology.
14. Deployment runbook (read or co-author). Existing runbook gets a vendor read; if no runbook exists, this becomes a first-week deliverable.

Section C: Decision-Making Contracts (5 items, owned by buyer)

Day 1-2:

15. Named tech lead on each side. One vendor tech lead, one buyer tech lead. They are the one-throat-to-choke for each side.
16. Architectural change protocol. Who approves changes that affect data model, integration surface, or non-functional requirements? Default: buyer tech lead with 24-hour written response SLA.
17. Scope boundary definition. What is "minor scope" (vendor proceeds without permission) vs "change request" (vendor proposes, buyer approves)? Agree at Day 1, written into engagement notes.
18. Demo and acceptance cadence. When are demos? Who attends? What is the written acceptance protocol per increment? Default: end-of-sprint demo, written acceptance within 48 hours.
19. Standup cadence. Daily? 3x/week? When in the day? Async-only? Written down at Day 1 to avoid drift.

Section D: Eval Expectations (5 items, vendor-led with buyer co-design)

Day 2-5:

20. Eval set size target. 200+ reference cases for AI agent / RAG engagements, smaller for traditional software. Numeric target written at Day 2.
21. Scoring rubric definition. Pass-fail per case? Score 1-5 per case? Multi-dimensional scoring? Domain owner (buyer side) and tech lead (vendor side) co-author by Day 5.
22. Source of reference cases. Real historical workflow logs (preferred), synthetic cases (acceptable), prompt-generated (last resort). Document at Day 3.
23. CI gating threshold. What pass rate must the eval clear for code to merge? Default 90% for low-cost-of-error workflows, 95%+ for high-cost-of-error workflows. Agreed at Day 3.
24. Eval cadence post-launch. Nightly + pre-deploy + on every model upgrade, agreed at Day 3 even if launch is months away.

Section E: Escalation Paths (6 items, owned jointly)

Day 1:

25. Critical incident protocol. Production-impacting incident at any time of day — who is on-call on each side, response time SLA, comms channel. Document at Day 1.
26. Architectural disagreement protocol. Vendor and buyer engineers disagree on a load-bearing decision. Who breaks the tie? Default: buyer tech lead with 24-hour SLA. Document the escalation path.
27. Scope-creep protocol. Mid-sprint scope expands beyond the change-request threshold. Who pauses? Who calls the escalation? Default: vendor tech lead pauses + writes a change-request memo within 48 hours.
28. Quality-bar disagreement protocol. Vendor ships an increment that buyer thinks fails acceptance criteria. Who arbitrates? Written acceptance criteria from Day 1 (Item 18) handles most cases; for ambiguity, escalate to engagement sponsor.
29. People-changes protocol. Vendor wants to swap a named tech lead or engineer. Buyer's notice and approval window. Default: 2 weeks notice + buyer approval required for tech lead changes.
30. Engagement-end protocol. What happens at handover? Who maintains? Who owns the runbook? When does the 6-month QA window start (and end)? Documented at Day 1, even though it is a Day 100 event.

Day-by-Day Timeline

The complete 30-item checklist clears in 3 working days when both sides commit:

Day 0 (pre-kickoff, 1 week prior): Buyer pre-provisions Section A items 1-3 (the longest-lead). Vendor sends a list of named engineers + their email addresses.

Day 1 (kickoff): Section A finalized (1-8). Section C agreed (15-19). Section E drafted (25-30). Kickoff meeting documents the named tech leads, decision protocols, and escalation paths.

Day 2: Section B starts (9-12). Section D launches (20-22). Vendor team reads ADRs, walks system diagram, asks questions in writing.

Day 3: Section B finalizes (13-14). Section D agrees on rubric and CI gating (23-24). End of Day 3: full checklist marked complete, written sign-off by both tech leads.

Day 4-5: Eval set co-build kicks off if not already running. First sprint planning happens with both sides aligned on what "done" looks like.

This timeline saves week 4. With it, the engagement is shipping its first production change by week 2-3. Without it, week 4 is still "we are waiting on staging access."

Mid-Engagement Re-Run Protocol

Onboarding is not a one-time event. Re-run the checklist at week 6 and at any of these triggers:

• Vendor swaps a tech lead or adds a new senior engineer
• Buyer adds a new system integration to scope
• Production traffic increases by 3x or more
• A regulatory or security review introduces new constraints

The mid-engagement re-run is faster — usually 4-6 hours over 2 days — because Sections A and C rarely change. The active sections are B (code-base orientation for new team members), D (eval expectations adjusted to current state), and E (escalation paths re-confirmed).

Three Patterns That Signal Broken Onboarding

Even when the 30-item checklist is "complete," three patterns mean it is not:

Pattern 1: The vendor's first PR after onboarding is cosmetic. A senior vendor onboarded properly opens a non-trivial PR by end of week 1 — refactoring a load-bearing module, adding observability to a critical path, building the eval test harness scaffold. A vendor whose first PR is "fix typo in README" is signaling they have not yet built confidence in the codebase. This is an onboarding gap, not a vendor competence gap. Re-run Section B.

Pattern 2: The vendor asks the same architectural question twice in two weeks. Once is normal. Twice is a sign that ADR documentation is incomplete or the original answer was not written down. Re-do the ADR tour and write down the answer.

Pattern 3: A critical incident escalates outside the documented channel. Section E exists for a reason. When an incident escalates via direct text to the engagement sponsor's personal phone instead of the documented incident channel, the protocol has broken down. Re-confirm Section E within a week, even if the incident itself was resolved.

How DevStudio Approaches Onboarding

DevStudio engagements run the 30-item checklist as the first deliverable. Day 0 (pre-kickoff): Section A items 1-3 pre-provisioned by the buyer with our written guide. Day 1-3: full checklist cleared, written sign-off by both tech leads, eval co-build kickoff scheduled. Day 5: first eval set drafted, first non-trivial PR opened.

This is part of why our 4-10 week project-rate engagements ship on time. The first three days are fully spent on onboarding, which means the remaining 30+ days are fully spent on engineering. The About page has more on our engagement model.

FAQs

Who owns running the checklist on the buyer side?

The buyer's named tech lead from Item 15. If the buyer does not have a named tech lead, the engagement sponsor temporarily owns it until one is appointed. Without a named tech lead on the buyer side, the checklist will not clear in 3 days.

What if our company's procurement process makes Section A items take 2 weeks?

Two paths. First, escalate procurement to the engagement sponsor in pre-kickoff so access is provisioned before Day 0. Second, structure the engagement timeline to start engineering in week 3 instead of week 1 — and pay the extra two weeks of vendor bench cost as part of the procurement-friction tax. Both are better than the silent option of letting the engagement drift.

Does this checklist apply to non-AI software engagements?

Most of it. The AI-specific items are Section D (eval expectations) and parts of Item 13 (eval set introduction). For traditional software engagements, replace Section D with QA / test discipline expectations: test coverage targets, CI gating thresholds, performance benchmarks. Sections A, B, C, E apply directly.

How does this work for a small (1-2 person) vendor team?

Compress the timeline: 30 items can clear in 1.5 days for a 1-2 person vendor team because Section B (code-base orientation) is faster with one tech lead. The substance is the same; the velocity is faster. Do not skip items because the team is small — Section E (escalation) is especially important when the team is small because there is no internal redundancy.

Can the vendor refuse certain checklist items?

Yes, two reasonable refusals: (1) Item 8 secrets management at the vault level — some vendors have their own secrets management posture that is at parity or better; document the alternative, do not skip; (2) Item 26 architectural disagreement protocol where the vendor wants final architectural authority on a specific surface — uncommon, only acceptable for vendors selling specific platform IP. Be skeptical of broader refusals.

What if the vendor finishes the 30 items in 1 day, not 3?

Validate by sample-checking. Pull 3 random items, ask the named owner to walk through them in detail. If the walkthrough is sharp, accept the 1-day completion as evidence of vendor preparation. If it is shallow, treat the "complete" as paperwork compliance and re-run the items.

Does Eval Week 1 depend on the checklist being done?

Yes — Eval Week 1 cannot start without Items 1-2 (source + cloud access), Item 9-10 (code-base understanding), and Item 22 (reference case source). The checklist is not optional infrastructure for Eval Week 1; it is a hard prerequisite. See the Eval Week 1 framework for why this dependency matters.

How does this compare to an internal team's onboarding?

Internal team onboarding takes 4-12 weeks (covered in Outsourcing vs In-House AI Development). Senior vendor onboarding takes 3 days. The gap is real, durable, and a meaningful part of why outsourcing wins on time-to-first-feature for projects under 18 months.

Related Reading

• How to Choose an AI Outsourcing Team: 5 CTO-Level Checks
• Software Outsourcing RFP Template
• Software Outsourcing Contract Checklist
• How to Accept an AI Outsourcing Project
• AI Agent Eval Framework: Why You Need It in Week 1
• AI Project Scoping Checklist (50-item readiness + Paid Scoping framework)

Last updated: May 31, 2026