Software agency · Engineering
Developer onboarding to a client project
Get a developer who joins a running project to a first merged change quickly, without days lost to access and setup. The client approves the new team member and grants access through a shared link, and sprint work stays locked until the engineering lead confirms the developer is ready.
- Duration: 1 to 2 weeks
- How often: Every time a developer joins a project
- Steps: 9 steps
- AI agents: 1 AI agent
- Approvals: 1 approval
Free plan, no credit card needed.
What changes with this template
Without it
The new developer waits days for client access.
The setup guide is out of date, and every newcomer loses a day to it.
Onboarding is a single call and a link to the repository.
The client hears about a new team member in a sprint demo.
With it
The client approves and grants access through one link before the start date.
Each developer records the gaps, and the guide is updated before they are signed off.
A buddy walks the developer through the codebase and reviews their first change.
The client approves every new developer before they get access.
The template, step by step
Each step says who does it: someone on your team, an AI agent, or the client through a shared link. An approval keeps every later step locked until it is given.
- Done by your team
- Done by an AI agent
- Done by the client, through a shared link
Starts when
A developer joins a running client project, as a new hire or from another project. The project manager starts a run with the developer's name and start date.
- 1
Announce the developer and share the client link
Before day 1Project manager · Team
Email the client who joins, from when, in what role and with which email address, and send the shared link for their approval and the access they need to grant.
Checklist
- Contract allows the change in the team
- Confidentiality agreement signed by the developer
- Shared link sent to the client
Fields to fill in
- Developer name (required)
- Developer email (required)
- Start date on the project (required)
- 2
Client approves the developer and grants access
Before day 1Client contact · Shared link
Through the shared link, the client approves the new team member and grants access to their systems, or notes what has to happen first, such as their own security training.
Checklist
- Access to the code repository granted
- Access to the staging environment granted
- Client accounts or VPN set up
Fields to fill in
- Approval (required)
- Conditions before access
- 3
Set up access and the local environment
Days 1 to 2Developer · Team
Accept every invitation, set up the project locally from the setup guide and note where the guide was wrong or incomplete. If an access is missing, mark the run blocked and note which one.
Checklist
- App runs locally
- Tests run locally
- Staging and the issue tracker work
Fields to fill in
- Gaps in the setup guide
- 4
Walk through the codebase
Days 2 to 3Onboarding buddy · Team
Walk the developer through the architecture, the main flows, the deployment and the team's conventions, and introduce the client contacts and rituals.
Checklist
- Architecture and main flows explained
- Branching, review and release rules explained
- Client contacts and rituals introduced
Fields to fill in
- Topics to revisit
- 5
Deliver a first small change
Days 3 to 5Developer · Team
Pick a small ticket with the buddy, build it with tests and open a pull request.
Checklist
- Ticket agreed with the buddy
- Tests added
- Pull request opened
Fields to fill in
- Link to the pull request (required)
- 6
Review the first change together
Hidden from the shared linkDays 4 to 5Onboarding buddy · Team
Review the pull request with the developer, explain the feedback and merge it when it meets the team's standards.
Checklist
- Reviewed with the developer
- Feedback explained
- Merged
Fields to fill in
- What to focus on next
- 7
Check readiness
Hidden from the shared linkDay 5Readiness checker · AI agent
The readiness checker compares the checklists and fields of every earlier step with the onboarding list in its instructions, lists what is still open and writes a short readiness summary.
Fields to fill in
- Open items
- Readiness summary (required)
Checked by: The engineering lead closes the open items and confirms readiness in step 8.
- 8
Confirm the developer is ready
Hidden from the shared linkDay 5Engineering lead · Team
Read the readiness summary, close or plan the open items and confirm the developer can take on sprint work.
Checklist
- Open items closed or planned
- Setup guide updated with the gaps found
Approval: Sprint work stays locked until the engineering lead confirms the developer is ready.
- 9
Add the developer to the sprint and tell the client
Week 2Project manager · Team
Add the developer to the next sprint and the project's team list, and let the client know they are fully onboarded.
Checklist
- Added to the sprint plan
- Added to the team list
- Client informed
Fields to fill in
- First sprint starts (required)
Done when
The developer has working access, knows the codebase and has a first change reviewed and merged, and the client knows who joined.
Make it yours. Rename steps, change owners and add checklist items, fields or approvals. The template is a starting point for the way your team works.
The AI agents in this template
An agent only works on its own steps, and a person on your team checks what it did. Anything an agent writes to a connected app waits for approval unless you allow it.
Readiness checker
Checks what is still open in the onboarding and sums up where the developer stands.
What it does
- Reads the checklists and fields of every earlier step
- Compares them with the onboarding list in its instructions
- Lists open items and writes a short readiness summary
- Completes its step, so the engineering lead can review
Checked by: The engineering lead closes the open items and confirms readiness in step 8.
Questions this template answers
Get the client's approval and access first, then a working local setup, a codebase walkthrough and a small first change. This template runs those in order, from the client's approval in step 2 to the engineering lead's readiness check in step 8.
Aim for a small, reviewed change in the first week, so setup problems and gaps in understanding show up early. In step 5 the developer delivers a first small change with tests, and in step 6 the onboarding buddy reviews it with them.
Tell the client who joins and from when, and let them approve before any access is granted. In step 2 the client approves the new team member and grants access through the shared link, or notes their conditions first.
Let every new developer follow it to the letter and record where it was wrong. In step 3 the developer notes the gaps in the setup guide, and in step 8 the engineering lead checks that the guide was updated.
Let AI check what is still open across the onboarding and sum it up, and keep the decision with the engineering lead. In step 7 the readiness checker lists open items and writes a summary, and step 8 is an approval gate where the engineering lead confirms the developer is ready.
Give every move the same onboarding, with a buddy and a readiness check, instead of a quick handover call. In steps 4 to 6 the onboarding buddy walks the developer through the codebase and reviews their first change, and the run shows what was covered.
Run this workflow in OKiDO
Set up the steps, owners and approvals once, then start a run for every new case.