Onboarding a Freelance Developer: 10-Point Checklist for Day One

Here's my checklist for onboarding a freelance developer: ten things to have ready before the first billable hour, from repository access and test data to one person who can make decisions. Get them in place, and your developer spends day one on your product instead of chasing logins. The list is written from the developer's side of the table.

The short answer: the day-one checklist

If you're still choosing who to bring in, start with my guide to hiring a developer.

Access: code, hosting, staging and services

1. Repository access

Your code should live in a repository owned by your company, on GitHub or GitLab. Invite the developer as a named user, so you can see who changed what and revoke access in a minute. If the code still sits in a previous contractor's or agency's account, move it before day one. More on why in my post on who owns the code when you hire a freelancer.

2. Hosting and production access

The developer needs to see how the system runs: hosting, database, error logs and how new code gets deployed. Give the least access that still lets them do the job. Read-only access to production is often enough at the start. Unsure which accounts exist? Make that list together on day one.

3. A staging environment with test data

A staging environment is a copy of your system where changes can be tested without customers noticing. Set up test users for each role, such as admin and customer. Use test or anonymized data, not a copy of the live database. If there's none, building one is often an early task that usually pays for itself quickly.

4. Third-party services and API keys

Most products rely on other services, such as an email provider, HubSpot or Xero. List them, and invite the developer as a user wherever possible. Payment providers like Stripe offer sandboxes with test API keys and test cards, so no real money moves while you build.

People: who answers, and where

5. A point of contact who can decide

Name one person who can answer questions and make calls about what gets built. They don't need to be technical, but they need to know the business and reply within a working day. Agree on a stand-in for holidays. Some of the most expensive days in a project are spent waiting for answers, or guessing and redoing the work.

6. One channel, a rhythm and overlapping hours

Pick one place for questions (Slack, Teams or email) and one place for tasks (Linear, Jira or Trello). Agree on a weekly check-in and on how bugs get reported: what happened, where, plus a screenshot. If you're in a different time zone, agree on the hours you overlap. Central Europe and the US East Coast typically share only a couple of working hours, so hold live calls then and keep the rest in writing.

Goals and terms for the first weeks

7. A goal for the first two to four weeks

"Improve the platform" isn't a goal. "Customers can pay by card at checkout by May 1" is. Choose the first deliverable, define when it's done, and prioritize the rest later. My advice is to keep that first goal small, so you quickly learn whether the collaboration works. If you haven't written anything down yet, use my project brief template.

8. The terms in writing

Before the first hour, agree on scope, price and how time gets reported. On an hourly or day rate, set a weekly or monthly cap. On a fixed price, check what it covers. If the developer can access personal data about your customers or staff, they usually act as your processor under the GDPR, and Article 28 requires a written contract covering that processing. Check the rest against my freelance developer contract checklist.

Knowledge: documentation and history

9. Existing documentation

Put everything in one folder: old specs, Figma designs, the README (a short guide stored with the code) and notes on key workflows. Include the outdated parts and flag what's wrong. They still show the original intent. If there's almost nothing, my software documentation checklist is a good starting point, and the developer can fill gaps as they go.

10. The history and known problems

The most useful knowledge rarely sits in a document. Why did the last developer leave? Which parts of the system is everyone afraid to touch? What do customers complain about, and what has already been tried? Book an hour where someone who knows the system walks the developer through it, so they don't rediscover old problems on your budget.

What the first week should look like

A good start usually follows four steps:

1. Two to three days before: the contract is signed and access is sent, so the developer can check that everything works.
2. Day one, first hour: a kickoff call with your point of contact covering the goal, the system and its history.
3. Day one, the rest: the developer gets the system running locally, reads the code and collects questions.
4. First week: a small task that goes all the way from change to testing to production.

I'd push hardest for that last step. A small task that reaches production exposes gaps in access, staging and communication far more cheaply than a big feature stalling in week three.

When this list is overkill, and when it isn't enough

If a developer is fixing one bug on your website in five hours, you don't need all ten items. Code and hosting access, a contact person and a clear problem description will do. I cover that setup in my post on hiring a developer for a small project.

But no checklist replaces someone in your company who owns the product. A freelancer like me can ask the right questions, but can't decide what your business needs. If you can't free up a contact with time and authority, consider an agency with a project manager who can cover part of that role. It costs more, but less than building the wrong thing.

Next steps

Go through the checklist a week before your developer starts. Anything missing can be sorted together in week one, as long as you both know those hours are onboarding. Still choosing? Use the list as a test: a good developer asks for most of these items unprompted.

With me, you work directly with the developer who writes the code, and the code lives in your repository from day one. See how I work and what I can build for you.

Frequently asked questions

Should I pay for a freelance developer's onboarding time?+

Yes, in most cases. Onboarding is real work: reading code, setting up the system locally and asking questions. How long it takes depends on the system's size and your preparation. On a fixed-price project it's normally built into the quote. On an hourly or day rate, ask for an onboarding estimate up front.

How long before a freelance developer is productive?+

On a small, well-organized codebase, a developer can usually ship something useful within the first few days. On a larger system with little documentation, it can take a few weeks before they work at full speed. The biggest factors are code quality, documentation and how quickly questions get answered.

Should a freelancer get access to the production database?+

Not on day one, and often not at all. Most work can be done in staging with test data. Some bugs only show up in real data, and then temporary read-only access may be needed. Grant it for a specific task, remove it afterward, and make sure a data processing agreement is in place if there's personal data.

What should I do with access when the engagement ends?+

Revoke it the same day. If the developer had a named user everywhere, offboarding means disabling those users rather than changing every password. Do rotate any API keys and shared credentials they had access to. Keep the access list from onboarding and reuse it as your offboarding checklist.