A 30/60/90-day plan for onboarding remote developers

What should your 30/60/90-day onboarding plan achieve?

Give each developer a named manager, a first task and written expectations before they start. Reserve time for the existing team to teach and review. Put those commitments on the calendar alongside the new hire's milestones.

Use this plan as a proposed working schedule. Adjust the scope for seniority, system complexity and release controls. The dates are review points, not promises that every developer will reach the same level of independence.

When you hire dedicated developers, budget for the manager's time as well as the hire's rate. A developer with an empty backlog and an unavailable reviewer cannot meet a useful delivery target.

Prepare the work before day one

Choose an engineering manager who can set priorities and judge the work. Assign a technical buddy who knows the codebase. Name a backup for both roles so leave does not stop onboarding.

Create an access checklist with an approver for each system. Include source control, issue tracking, documentation and the development environment. Add staging access where the first task requires it.

Grant access based on the work. Keep production permissions behind your usual approval process. Use individual accounts and your company's authentication rules. Never put shared passwords or production secrets in an onboarding document.

Write the first task before the developer arrives. Pick something small enough to review without a long design debate. A useful task has a clear user need, acceptance criteria and a known reviewer.

Prepare a short product walkthrough. Show who uses the product, what they are trying to do and where the assigned team fits. Include a recent support issue so the developer can connect code to a user's problem.

For a whole team, map responsibilities across the shared backlog. State who owns each service or interface and who decides when work crosses those boundaries. Give everyone the same product context while keeping individual milestones tied to their roles.

Use days 1–30 for supported contributions

Start with a live setup session. Ask the developer to run the application and its tests, then record any step that fails. The technical buddy should help fix the instructions while the problem is visible.

Walk through a recent change from ticket to release. Explain why it was needed, how it was tested and what reviewers asked. Show the rollback path and where the team checks for errors after deployment.

Use the first task to practice that same process. The developer should be able to explain the change, describe the tests and respond to review comments. Keep normal quality checks in place.

Schedule short check-ins during the initial setup period. Give the developer a place to raise a blocked account or an unclear requirement without waiting for a formal meeting. As setup settles, move updates into the team's usual rhythm.

At the first monthly review, inspect actual work:

• Can the developer run the application and relevant tests?
• Can they explain the part of the product they changed?
• Did the change meet its acceptance criteria?
• Do they know whom to ask when a decision or permission blocks progress?
• Have they improved the setup notes for the next hire?

Record what your team still owes them. An unresolved access request should have an internal owner and a due date. Keep it separate from feedback about the developer's skills.

Use days 31–60 for bounded ownership

Assign a piece of work with a clear boundary, such as an API change or a small product feature. Ask the developer to outline the approach before coding. Review dependencies and test coverage while changes are still cheap.

The manager should make priority calls. The developer should raise uncertainty, propose options and explain the cost of a blocked decision. Agree on when to escalate rather than leaving that judgment implicit.

Give feedback against the work. Replace "be more proactive" with a concrete request: flag a missing dependency in the ticket and contact its owner before continuing.

At the second monthly review, assess the full task. Look at how the developer clarified requirements, handled review and checked the release. Discuss where they still needed help and whether that help was reasonable for the scope.

If progress is weak, narrow the next assignment. Identify the skill or process that needs work and name the person who will help. Set a review date with evidence both sides can inspect.

Use days 61–90 for sustained delivery

Keep the developer responsible for an agreed area long enough to see how they handle follow-up work. Include a defect or maintenance task where appropriate. This gives the manager more evidence than a single feature.

Ask the developer to review another teammate's change within their knowledge. Look for useful questions about behavior and tests. Explain how to raise concerns without taking over another person's work.

Before assigning incident duties, check readiness through a walkthrough or supervised exercise. Confirm access, escalation contacts and the limits of the role. Add live responsibility only after your normal readiness checks.

At the final review, decide what the developer can own next and what support should continue. Write down the scope, unresolved gaps and next review date. Avoid treating the calendar alone as proof of readiness.

Adapt the first task to the stack

If you hire dedicated React developers, start with a small interface change that uses your existing components. Review keyboard behavior, loading states and tests alongside the visual result.

If you hire dedicated mobile developers, prepare test devices and signing access before assigning release work. Use a test build to check the full build process and document who approves distribution.

For .NET developers, explain service boundaries and environment configuration before assigning a backend change. Use the task to review authentication, data access and deployment assumptions in context.

What does hiring data tell you about onboarding a nearshore team?

SHRM's 2025 recruiting findings put median time to fill at roughly a month and a half for executive and nonexecutive positions. Its measure runs from job requisition to offer acceptance. SHRM's recruiting findings

That measure ends before onboarding begins. Use separate dates for offer acceptance, first day worked and the first agreed delivery milestone. A hiring schedule cannot tell you when a developer will understand your system.

For your own onboarding reviews, keep a small record of events. Capture when access was ready, when the first change entered review and when feedback arrived. These dates help a manager locate delays without inventing a universal productivity target.

Avoid using lines of code as a completion rule. Review whether the assigned work met its requirements and passed the team's checks. A small change may require substantial investigation.

Set overlap by city and agreed working hours

Mexico City is UTC−6 year-round. Tijuana observes daylight saving time, so a country label alone does not define the schedule. IANA's North America time zone records

Bogotá is UTC−5 year-round. Buenos Aires and São Paulo are UTC−3 year-round. IANA's South America time zone records

Put the developer's city and the US team's time zone in the onboarding plan. Agree on a shared window for pairing and review. Recheck recurring meetings when US clocks change.

Ask which holidays and planned leave affect the onboarding period. Put them in the team calendar before choosing milestone dates. Name a backup reviewer for days when the main contact is away.

Overlap only helps if the people who can unblock work are available. Reserve reviewer time inside that window, especially while the developer is learning the system.

How do hiring models change your onboarding responsibilities?

Choose the model based on which responsibilities you want to keep and which you want a provider to handle. Put the split in writing before setting a start date.

For an agency placement, request a handoff that captures the role expectations discussed during hiring. Check that the manager and developer agree on seniority and responsibilities before the first task.

With an employer of record, make technical ownership explicit. Name the person who provides repository access and reviews the work. Confirm which employment questions should go to the provider.

For team augmentation, place developers inside your existing process, tools and backlog. Give them access to the same decisions that affect the rest of the team. Record scope changes where they can see them.

Project outsourcing requires a different delivery agreement. Do not use its acceptance structure as a substitute for managing developers who work inside your team.

For every model, ask how knowledge and access will be handled if someone leaves. Keep decisions, setup instructions and code in company systems from the start.

What should you ask a provider before the start date?

Ask for a handoff with named owners and dates. A broad promise of onboarding support does not tell your manager who will resolve a delayed laptop or an employment question.

Use these questions in the final hiring discussion:

1. Who confirms the first working day, and what could change it?
2. Who provides equipment, and how is readiness checked?
3. Which setup tasks belong to the provider and which belong to us?
4. What working hours has the developer agreed to?
5. Who handles payroll, benefits and leave questions?
6. How do we raise a concern about the placement?
7. What happens if the developer leaves during onboarding?
8. Who coordinates access removal and the return of company equipment?

Then review the engineering handoff. Ask what the candidate was told about the stack, seniority and expected ownership. Resolve any mismatch before it becomes a performance dispute.

Request the rate and billing terms in writing. Check when billing starts and how leave or a delayed start affects it. Keep commercial questions separate from the developer's technical review.

Agree on how concerns will be documented. The manager should bring examples from assigned work, along with the support already given. Ask the provider to name its contact and explain the next steps.

Decide how you will respond to a missed milestone

Review the blocker history before deciding that a hire cannot do the role. Check whether the task was clear, the environment worked and a reviewer was available.

If the gap is technical, define a smaller task that tests the missing skill. If the problem is communication, describe the update you need and when you need it. Give feedback directly to the developer.

Escalate repeated concerns through the agreed provider process. Keep a written record of expectations and work reviewed. A replacement discussion should follow evidence that both the manager and developer have seen.

Where does Opus fit in this onboarding plan?

This site is an Opus-owned reference; recommendations are editorial.

Opus finds, vets and installs the whole team. The client keeps operational control. The dedicated development team works inside the client's process, tools and backlog.

"The client chooses the finalist and manages day-to-day work."

That split leaves your engineering manager responsible for the plan described here. Assign the technical buddy, prepare the first task and reserve review time before the team starts.

Talk to Opus about your team.

Opus describes its pricing as follows: "Opus charges one flat monthly rate per hire. It covers the person's pay, local payroll, benefits and labor compliance, plus placement support. There is no separate recruiting fee. The rate depends on role, seniority and location."

Published dollar rates: Not published. Ask for a written quote for the roles and locations you are considering.

Opus states: "Every placement carries a lifetime replacement guarantee with no cap and no time limit."

Keep your onboarding records ready for any handoff. A replacement still needs product context, access and a reviewer. Ask how the replacement process would work for your team before agreeing on a start date.

Bring a draft onboarding plan to the hiring discussion. Include the manager's name, agreed overlap window and first task. For a whole team, add the role map and dependencies between workstreams.

Before day one, confirm that each task has an owner. At each review, use completed work and recorded blockers to decide the next scope.

Talk to Opus about your team.

<!-- File saving was skipped because the workspace is read-only; this page has not been saved to the requested path. -->