How to Onboard a Remote Developer in 2026: A Practical First 30 Days

You have signed the contract and your new developer starts on Monday. The next 30 days decide whether you get a productive teammate or an expensive person waiting for passwords. This guide is for founders, CTOs and operations leads bringing on a remote developer, often in a different time zone. It covers what to prepare before day one, a plan for day one, week one and days 8 to 30, what to measure at the end and the common mistakes.

Before day one: prepare the ground

Most failed onboardings fail before the developer logs in. Set aside two or three hours the week before.

The access list

• Code repository: GitHub, GitLab or Bitbucket, with the permission level they actually need.
• Project tracker: Linear, Jira, Trello or whatever holds your tickets.
• Chat and email: Slack or Teams, plus a company email address if you use one.
• Environments: staging, test accounts and seed data.
• Cloud and hosting: read-only to start. Widen it once you trust the setup.
• Password manager: a shared vault for anything that is shared, so nothing gets pasted into chat.

Send invitations two days early and ask the developer to confirm each one works. Invitations expire and two-factor prompts go to the wrong phone. Better to find out on Thursday than at 9am on Monday.

A written "how we work"

One page is enough. It should answer: working hours and overlap hours, where decisions are written down, how to ask for help and how fast to expect an answer, how code gets reviewed and merged, what "done" means, and who to contact for what. For a team spread across time zones, this page does the job a desk neighbour does in an office.

A first small task

Pick a ticket that touches real code, can ship in two or three days and carries little risk: a bug fix, a small interface change, a missing validation. Write it up with acceptance criteria. Avoid "get familiar with the codebase". It has no end.

Day one: access, people and one clear goal

1. A 30 to 45 minute video call: introductions, the product, the customer and why the work matters.
2. Check every account works while you are both on the call.
3. Get the project running locally. Every missing step in the README becomes their first documentation fix.
4. Hand over the first task and agree when they will next check in.

Hold the call inside your overlap window. London and Lagos share most of the working day. Nairobi is two or three hours ahead of London, depending on the season. From New York the overlap is shorter, so book it for your morning.

Week one: ship something real and small

The goal of week one is one merged change, live or at least on staging.

• Codebase walkthrough: 60 to 90 minutes with someone who knows the code. Cover the architecture, where data lives, deployment and the fragile parts. Record it.
• Fast first review: review their first pull request within one working day.
• Ship it: pushing one change through the whole pipeline (branch, review, tests, deploy) exposes every broken step in your process.
• End-of-week note: ask for a short written summary of what they did, what confused them and what they would change.

If they are blocked for more than half a day in week one, treat it as your problem to fix, not theirs.

Days 8 to 30: ownership and rhythm

Give them a slice to own

By week two, hand over a defined area: a feature, a service, the admin dashboard, the settings screens of the mobile app. Ownership means they make the first call on decisions in that area and you review them. This shows whether someone can think, not only close tickets.

Set the check-in rhythm across time zones

• Daily written update in one agreed channel: done, next, blocked. Two or three lines.
• One weekly call of 30 minutes, inside the overlap hours.
• An urgent-issue rule: what counts as urgent, and how to reach someone outside working hours.

More written context beats more meetings.

The first review, around day 14

Thirty minutes, both directions. You give feedback on quality, communication and pace. They tell you what is missing, unclear or slow in your setup. Raise concerns here, not at day 60.

Hours online tell you when someone was at a keyboard. Merged work tells you whether you hired the right person.

What to measure at day 30

• Shipped work: how many changes were merged and deployed, and how big they were.
• Rework: how much back and forth their pull requests need. It should be falling.
• Communication: updates arrive on time, are clear, and flag blockers early.
• Independence: given a vague ticket, they come back with good questions rather than guesses.
• Ownership: their slice moves without you chasing it.

Do not expect full speed yet. As a rough guide, a capable developer on a medium-sized codebase is usually doing useful independent work within a month and reaches full pace somewhere in months two to three. Codebase size, the state of your docs and domain complexity move that range.

Common mistakes

• No access on day one. You lose a day and set the tone for the month.
• No written context. A developer five hours away cannot tap you on the shoulder.
• Judging by hours online. A green dot is not output, and someone working during your night will look absent.
• A first task that is too big. A three-week first ticket hides problems for three weeks.
• No named contact. If helping the new hire is everyone's job, it is nobody's.

The 30-day onboarding checklist

• Before day one: all accounts invited and confirmed, one-page "how we work" written, first task written with acceptance criteria, one contact named, welcome call booked inside the overlap.
• Day one: intro call held, project running locally, first task handed over.
• Week one: recorded codebase walkthrough, first pull request reviewed within a working day, first change shipped, end-of-week note received.
• Days 8 to 30: a slice assigned to own, daily written update and weekly call in place, two-way review held around day 14, day-30 check against the measures above.

Next steps

If you have not hired yet, you can browse developer profiles on DevDey for free, with no account needed. Look for the DevDey Verified badge, which means an interview plus an identity check. Posting a job is also free and DevDey takes no commission: you pay the developer directly under your own contract. DevDey contracts let you set milestones and mark them off as work lands. For the rhythm after the first month, read our guides on scheduling work across time zones and async communication for remote teams.