The first week sets the pattern for everything after it. A developer who spends three days waiting for passwords learns that your project moves slowly. A developer who ships something small by day three learns the opposite. You do not need a formal programme. You need access ready, context written down, a clear first task and a rhythm for talking.
Before day one: access and accounts in your name
Prepare access before the developer starts. Make a list and work through it:
- Code repository, such as GitHub, GitLab or Bitbucket
- Hosting or cloud account, staging first
- Domain and DNS, only if the work needs it
- Project tracker and chat tool
- Design files and any third-party dashboards the work touches
- A test account for your app or site
Create each account under your business and invite the developer as a user. Do not let them set up the repository, hosting or app store accounts in their own name. If the arrangement ends, you should be able to remove their access in minutes and keep everything. This applies to freelancers, agencies and dedicated developers alike.
Give them context, not just credentials
A remote developer cannot overhear the office. Anything they need to know has to be written down. A short document is enough:
- What the product does and who uses it
- The current priorities, in order
- How the code is deployed and where the test environment is
- Known problems and areas to be careful with
- Who to ask about what: product, design, content, access
If you already have a brief, share it. If you do not, the developer brief guide covers most of what belongs in this document. Ask the developer to note anything confusing as they read. Those notes become better documentation for the next person.
Add a short call where you use the product the way a customer does. A few minutes of watching you click through it shows priorities that a document misses.
A small first task, shipped early
Choose something real, small and low risk. A bug fix, a copy change, a small form improvement. The goal is not the task itself. It is to run the whole path once: pull the code, run it locally, make a change, get it reviewed and deploy it to staging.
That path is where hidden problems show up: missing environment variables, outdated setup notes, access that was forgotten. Better to find them on a small task in week one than on an urgent fix in month three.
Agree what done looks like before they start, and aim to see the change live on staging within the first few days.
Stay available while they work on it. Early questions are normal and cheap to answer. A developer who is left to guess in week one tends to keep guessing, and that habit is hard to undo later.
Set the communication rhythm
Decide early how and when you will talk, then keep to it. A simple rhythm that works for most teams:
- Daily: a short written update. What was done, what is next, what is blocked.
- Weekly: a call or screen share to demo progress and agree priorities.
- As needed: quick questions in chat, with an agreed reply time.
Say which channel is for what. Chat for quick questions, the tracker for tasks, email for anything contractual. If your developer is in a different time zone, read our guide to working with developers in India across time zones before you fix meeting times.
Security basics from the start
A few habits in week one prevent most access problems later:
- Use individual accounts, never shared logins
- Turn on two-factor authentication for the repository, hosting and email
- Share passwords and keys through a password manager, not chat or email
- Give the least access the work needs. Staging before production.
- Keep secrets such as API keys out of the code repository
- Keep a list of every account the developer can access, so offboarding is quick
At the end of week one
By Friday, check three things. The developer has every access they need and nothing they do not. At least one small change has gone through review and reached staging. You both know when and how you will talk next week. If all three are true, the onboarding worked. To see how we set up new placements, read how it works, or contact us to plan a start date.
Tell us what you are building. We reply by email, usually the same working day.
