Developer onboarding checklist for day one

Who this is for

This is for the person who owns a new developer's first day: an engineering manager, team lead, IT admin, or operations lead at a small or mid sized company. The Developer onboarding checklist for day one below assumes the new hire has a laptop and a start date, and that someone can grant access. It also works for contractors who join for a fixed project.

Day one is not just paperwork. A developer needs a working machine, the right accounts, a repository to read, and a person to ask when something fails. If any of those are missing, the first day turns into a queue of support tickets and the new hire learns that shipping here is slow.

The checklist is short on purpose. It covers what must happen before the first commit, not the full first month. You can add role specific items, such as database read access for an analyst or staging access for a support engineer, but keep the core list the same for every developer.

Before you begin

Prepare the basics before the start date. Send the welcome note three business days ahead with the start time, first day schedule, laptop status, and the name of the onboarding buddy. Include the office or remote address, the chat channel for questions, and a phone number for urgent problems.

Open the access requests early. Use the same request process you use for existing staff, with a named approver and a ticket number. Ask for read access to the main repository, write access to a personal branch, issue tracker access, chat access, calendar access, and the secret manager. Do not grant production write access by default. Most developers do not need it on day one.

Set up the machine and test it. Install the operating system updates, the company identity agent, the endpoint protection tool, and the approved browser profile. Create the local user account and check that the new hire can sign in to email and chat. If the laptop ships, track it and have a spare or a loaner plan.

Pick a first task that is small and real. A missing step in the setup guide, a broken link in the README, or a tiny bug with a clear fix works better than a training exercise. Write the expected outcome and the reviewer name. Tell the buddy to block time on day one and day two.

The checklist

Use this list as a live document. Copy it into the ticket or wiki page for the new hire, assign an owner to each line, and mark items done only when the developer confirms them. The point is not to collect checkmarks. The point is to remove waiting.

A developer who finishes day one should be able to sign in, run the app, open a pull request, and know who to ask for help. If the local build fails, fix the guide before adding more access. A broken guide is a support cost that repeats with every new hire.

• Confirm the laptop, charger, monitor, and any ordered peripherals arrived, boot, and connect to the network.
• Sign in to the company identity provider and enroll in multi factor authentication before opening any work email.
• Join the team chat channels, calendar invites, and distribution lists named in the welcome note.
• Get read access to the main code repository and the issue tracker, plus write access to a personal branch.
• Receive application credentials through the approved secret manager, never through chat or email.
• Run the local setup guide on the new machine and write down every missing package, permission, or step.
• Build and start the app locally, or run the smallest service if the system is too large for one machine.
• Make one small documentation fix and open a pull request to test the review path, reviewer response, and merge rules.
• Meet the onboarding buddy for a walkthrough of the repository layout, test commands, and support channels.
• Review the access list with the manager and remove anything that is not needed for the first week.
• Read the incident process and the support handoff, including who to call when a test or deploy fails.
• Book a short end of day check in to capture blockers and update the setup guide while the details are fresh.

What good looks like

A good first day feels quiet. The developer spends time reading code and running tests, not waiting for a password reset. The laptop works, the accounts work, and the first pull request gets a review from a real person. The buddy knows the plan and has time on the calendar.

Good access is narrow and documented. The new hire can read the code and the issues, and can write to a branch, but cannot touch production or customer data without a second approval. Credentials come from the secret manager, and the access request ticket shows who approved what.

Watch for the common failures. A laptop that arrives without a charger, a repository that needs a personal token nobody documented, a chat invite sent to the wrong address, or a first task that depends on a service the developer cannot reach. Fix the guide and the request template when you find them, so the next hire does not hit the same wall.

What to do next

On day two, give the developer a real ticket with a named reviewer and a clear definition of done. Pair on the first change if the codebase is large. Keep meetings light and protect a block of focus time. Ask for one improvement to the setup guide by the end of the week.

Review access after the first week. Remove temporary permissions, confirm that the developer can reach staging but not production, and check that the secret manager entries are tied to a role, not a person. Put a reminder on the calendar for the 30 day access review.

If the delivery platform itself is the bottleneck, fixing onboarding alone will not help. Delivery platform setup at $14,500/month is one option among others: a four week fixed scope engagement that builds pipelines, separate environments, secret management, infrastructure as code, monitoring, rollback, and two training sessions for your engineers. Use it when releases depend on one person or when the team is preparing for a security review, not when a single laptop needs a charger.

Frequently asked questions