How to Run a Custom Software Vendor Onboarding Checklist

You signed the contract, the kickoff call is booked, and everyone is optimistic. Three weeks later the vendor is still waiting on repository access, nobody agrees on what "done" means for the first milestone, and your Slack channel has gone quiet. The project is not failing because of engineering skill. It is failing because custom software vendor onboarding was treated as a formality instead of a project phase.

Onboarding a software development agency is a two-way setup job. You are provisioning access, environments, and context; the vendor is proving how they work, communicate, and escalate. Get this right and the first sprint starts on day one. Get it wrong and you pay for that ambiguity for months.

Below is the checklist we use when we start engagements, written from the client side so you can run it with any vendor you hire.

Key takeaways

Treat onboarding as a scoped phase with its own owner, deadline, and exit criteria, not a series of ad hoc Slack messages.
Provision access through named accounts and groups, never shared credentials, and revoke them the same way at offboarding.
Define "done" for the first milestone in writing, with a demo and acceptance criteria both sides agree on.
Agree on communication cadence, escalation paths, and response-time expectations before work begins.
Document the onboarding process so the second vendor, contractor, or new hire is faster than the first.

Before the kickoff: prepare your side

Most delays in week one are caused by the client, not the vendor. Someone has to own setup inside your company, and it should be one person with authority to unblock access requests, not a committee.

Name an internal owner and a technical counterpart

You need two roles on your side: a business owner who owns scope, budget, and priorities, and a technical counterpart who can answer architecture questions and approve access. If those are the same person, fine, but name them explicitly. Vendors stall when every question routes to a different stakeholder.

Assemble the context pack

Before the kickoff, gather what the vendor cannot guess:

Architecture diagrams, even rough ones, and the current state of the system.
Existing documentation, API specs, schema dumps, or design files.
Known technical debt, fragile areas, and things that must not break.
Compliance constraints: data residency, PII handling, audit requirements, industry rules.
Business context: who the users are, what success looks like this quarter, and what is politically sensitive.

Do not wait for perfect documentation. A messy diagram plus a 30-minute walkthrough beats a two-week documentation sprint.

The access and environment checklist

This is where onboarding most often stalls. Work through it as a list with owners and due dates, and track it in a shared document both sides can see.

Accounts and identity

Create named accounts for every vendor team member who needs access. No shared logins, ever.
Use groups or roles so you can grant and revoke in bulk.
Enforce multi-factor authentication and your existing SSO where possible.
Record who has what, and set a review date.

Repositories and CI/CD

Grant repository access at the right level: read for reviewers, write for contributors.
Decide branch strategy, review requirements, and who approves merges.
Confirm the vendor can run your build and test pipeline locally or in a sandbox.
Agree on commit conventions, license headers, and any code-quality gates.

Environments and data

Provide a development environment the vendor can deploy to independently.
Provide a staging environment that mirrors production closely enough to be meaningful.
Use anonymized or synthetic data wherever possible instead of production data.
Document how to seed the database, reset state, and roll back a bad deploy.

Third-party services

Cloud accounts, secret managers, and API keys, issued per environment.
Monitoring, logging, and error-tracking access so the vendor can debug their own work.
Design tools, issue trackers, and documentation spaces.
A clear list of services the vendor must not touch without written approval.

If you need help structuring this phase, teams often bring in a partner to run it properly rather than improvising access rules under deadline pressure. That is exactly the kind of groundwork covered in our custom software development services.

Run a kickoff that produces decisions, not vibes

A good kickoff is a working session, not a slideshow. Aim for two hours with both teams present, and leave with artifacts.

Agenda that works

Introductions with roles and decision authority, not just titles.
Business goals and the problem being solved, stated by you.
Technical walkthrough of the current system and its constraints.
Scope for the first milestone, and explicitly what is out of scope.
Ways of working: cadence, tools, hours, and escalation.
Risks and unknowns, captured as a list with owners.

Outputs to demand before the meeting ends

A written summary of decisions and open questions.
A first-milestone definition with acceptance criteria.
A named contact on each side for day-to-day and for escalations.
A date for the first demo.

Communication and ways of working

Most "the vendor is slow" complaints are actually communication design problems. Fix the design up front.

Define the channels

One channel for day-to-day questions, one for decisions, one for incidents.
A single shared issue tracker. Do not run two boards.
A weekly written update with progress, blockers, and next steps.
A standing demo or review slot that does not get cancelled.

Set expectations explicitly

Response-time expectations for normal questions versus urgent issues.
Working hours and time-zone overlap, written down.
Who can approve scope changes, and what triggers a change request.
How the vendor raises a blocker, and how fast you commit to responding.

Write these down even if they feel obvious. Ambiguity is where trust erodes.

Success criteria, governance, and the first sprint

Before the first sprint starts, agree on what success looks like at three horizons: the first milestone, the first quarter, and the engagement overall.

Make "done" testable

Replace vague goals with checkable statements. "The payments service handles refunds end to end in staging, verified by these five scenarios" is testable. "Improve the payments experience" is not.

Lightweight governance

A short weekly status with a written summary, not a status meeting for its own sake.
A monthly review of scope, budget, and risks against the plan.
A single place where decisions are recorded and dated.
A defined process for change requests, with impact on timeline and cost.

Offboarding from day one

Decide now how access gets revoked, how knowledge is transferred, and who owns the code and infrastructure when the engagement ends. Vendors who plan for this are usually the ones worth keeping. You can see how this plays out in practice in our past software projects.

The checklist, condensed

Name a business owner and a technical counterpart.
Send a context pack before the kickoff.
Create named accounts with MFA and group-based roles.
Provision repository, CI/CD, and environment access with owners and dates.
Provide safe data and a documented way to reset environments.
Run a decision-producing kickoff and circulate written outputs.
Agree on channels, cadence, escalation, and response times.
Define testable acceptance criteria for the first milestone.
Set up lightweight governance and a change-request process.
Document the whole onboarding so the next one is faster.

If you would rather have this phase run for you, our team at Avaton builds custom software and handles exactly this kind of onboarding setup for clients. You can talk to our team about your next engagement.

Frequently Asked Questions

How long should custom software vendor onboarding take?

For most engagements, plan one to two weeks from contract signature to the first sprint, depending on how complex your access and compliance requirements are. The access and environment provisioning is usually the longest part, so start it the day the contract is signed rather than waiting for the kickoff call.

What should be included in a software vendor kickoff checklist?

A solid kickoff checklist covers roles and decision authority, business goals, a technical walkthrough of the current system, first-milestone scope with acceptance criteria, ways of working including cadence and escalation, and a risk list with owners. The meeting should end with written decisions and a date for the first demo.

Should we give a new vendor access to production systems?

Generally no, at least not at the start. Give the vendor a development environment they can deploy to independently and a staging environment that mirrors production closely. If production access is genuinely required for debugging, use named accounts, least-privilege roles, MFA, and a review date, and never share credentials.

How do we define success criteria for the first sprint?

Write acceptance criteria that can be verified by a demo or a test, not by opinion. Specify the scenarios that must pass, the environment where they run, and who signs off. If you cannot describe how you would check it, the criterion is too vague to be useful.

How do we keep onboarding knowledge from leaving with the vendor?

Keep documentation, architecture decisions, and runbooks in your own repositories and tools, not the vendor's. Require written summaries of key decisions, record demos, and review access lists regularly. Planning your offboarding process during onboarding is the simplest way to avoid losing context later.

Cover: Photo by Ivan S on Pexels