How to onboard a remote engineer in 1 week

To onboard a remote engineer in one week, compress the program into three phases: day 1 is environment plus first merged PR, days 2 and 3 are paired PRs against real tickets, days 4 and 5 ship one user-visible change to production. The whole thing runs on async docs, recorded Looms, and a single shared Linear board. No five-week ramp, no "shadow the team for a sprint" theater.

This is the one-week-compressed version of a longer program. If you have more runway, the broader playbook for onboarding remote developers covers the full month. If you don't, keep reading.

Why one week is a real target, not a stretch goal

The instinct is that a week is too short. It isn't. The instinct comes from in-office onboarding habits that don't translate: campus tours, swag pickup, lunch with each team, a slow dependency install on a borrowed laptop.

Strip that out and the actual blockers are four things: an environment that runs, a ticket sized for a stranger, a reviewer who will respond inside two hours, and a deploy pipeline the engineer can trigger themselves. Every one of those is solvable on day one if you wrote the prep down before the engineer started.

The remote engineers we see hit first commit at a median of 27 hours from booking. That's not because they're faster. It's because the spec was clear and the dev container booted on the first try.

The non-negotiables you set up BEFORE day 1

These belong in a onboarding/ folder in your repo, written by whoever is currently the most onboarded person. If it's not written before the engineer logs in Monday morning, you are not running a one-week onboarding. You are running a two-week one and pretending.

• A single README.md at the repo root with: clone command, env setup, dev server command, test command, deploy command. Five lines, no prose.
• A .devcontainer or make bootstrap that gets the engineer to a running app in under 15 minutes. If yours takes longer, fix that first; you're paying for it on every onboarding.
• A Linear (or Jira, or Shortcut) ticket already in their name, tagged good-first-issue, scoped to under 4 hours of work. Real ticket, not a typo fix. We'll talk scoping below.
• A Loom (3 to 7 minutes) from the founder or tech lead walking through the codebase's main folders and why they exist. Record it once, reuse it forever. Loom is the right tool here; if you haven't standardized async video yet, our take on using Loom for engineering communication covers the patterns.
• A dedicated Slack channel (#onboarding-firstname) the engineer pings with blockers. One channel, not seven.
• Production deploy access on day 1, not "after they prove themselves." If you can't trust them with deploy access in week one, the engineer is wrong or the deploy pipeline is wrong.

If those six items aren't in place at 9am Monday, push the start. The engineer will charge anyway and you'll waste the week.

Hour-by-hour day 1 schedule

This is the schedule we recommend for an engineer starting fresh on a codebase they've never seen. Adjust for timezones. Times are in the engineer's local working hours.

9:00 to 9:30 - Voice kickoff

A 30-minute voice call (Zoom, Meet, whatever you use). Founder or tech lead, not HR. Cover: what the company actually does, who the user is, the one metric that matters this quarter, and the rough shape of this week. End with "any questions before you go heads-down." This is the only mandatory synchronous block of the week.

9:30 to 11:00 - Environment up

Engineer clones the repo, runs the bootstrap script, gets the app running locally. They watch the codebase Loom while the install runs. If anything in the bootstrap fails, that's the first PR they'll fix: a real README update for the next engineer.

If they aren't running by 11, that's a flag on your dev experience, not on them. Ship them an updated Loom while they wait, then fix the script after the engineer hits "running app" so the next one onboards in 90 minutes.

11:00 to 12:30 - Read the ticket and the surrounding code

The pre-assigned Linear ticket. Engineer reads the ticket, reads the affected files, opens questions in the onboarding Slack channel. Expectation: zero code written, lots of reading.

12:30 to 13:30 - Lunch

Yes, schedule lunch. Burnout starts on day 1 when nobody tells you to step away.

13:30 to 16:00 - First draft of the PR

The engineer writes the PR. AI assist is expected here, not optional. Cursor or Claude Code for the bulk of the edits, the engineer for the review and the edge cases. Every Cadence engineer is AI-native by default, vetted on Cursor / Claude / Copilot fluency in a voice interview before they unlock bookings, so this rhythm is already muscle memory for them. If you've hired through other channels, set the expectation explicitly on the kickoff call.

16:00 to 16:30 - PR opened, async review starts

Engineer opens the PR with a description that includes: what changed, why, what they tested, and any open questions. Reviewer (tech lead or peer) has a soft SLA of 2 hours.

16:30 to 17:00 - Friction log

Engineer writes a short doc in Notion: "what slowed me down today." This becomes the punch list for the next engineer's onboarding. Treat it like a postmortem, not a complaint box.

By end of day 1, the goal is: one PR open, reviewer assigned, no merged code yet. Merged code on day 1 is a vanity metric. PR opened with sensible description is the real one.

Days 2 and 3: paired PRs and the real work

Day 2 starts with the day 1 PR getting merged (assuming reviewer turned it around overnight or first thing). Then the engineer takes two more tickets, both mid-sized, both reviewable in under 30 minutes.

The pattern we recommend: one PR per day, paired with a "buddy" engineer who reviews it within 2 hours. The buddy isn't there to babysit. They're there to unblock and to give the engineer confidence that someone is actually reading what they ship.

Rituals on days 2 and 3:

• Async standup in the onboarding channel. Three things: what shipped yesterday, what's open today, what's blocked. We have a separate post on running async standups for engineering teams if you haven't standardized this yet.
• One Loom from the engineer per day, 60 to 90 seconds, walking through the PR they opened. Forces them to articulate the change and gives the reviewer a head start.
• Daily rating (Cadence pattern): the founder or tech lead drops a 1-to-5 in a private channel. Five categories: speed, code quality, communication, autonomy, judgment. Takes 90 seconds. Compounds into a usable performance signal by Friday.

By end of day 3, the engineer should have 3 merged PRs and a clear sense of the codebase's shape. If they don't, the issue is almost always ticket sizing, not the engineer. The tickets you assigned were too big or too vague.

Days 4 and 5: ship to prod

Days 4 and 5 are the milestone that proves the week worked: one user-visible change deployed to production, owned by the engineer end to end.

This is non-negotiable for a one-week onboarding to mean anything. "Ramped" without a production deploy is the same as "not ramped." The engineer needs to have touched the deploy pipeline, fixed something that surfaced after deploy, and watched the change in the real monitoring tools (Sentry, Datadog, Vercel Analytics, whatever you use).

Day 4 morning: pick the ticket. Should be user-facing (a UI change, a new API endpoint, a fix that resolves a customer ticket). Not a refactor. Not a test. Something a user will notice.

Day 4 afternoon to day 5 morning: build, review, merge.

Day 5 afternoon: deploy. The engineer pushes the button, watches the rollout, confirms the metric moved (or didn't), and writes a one-paragraph retro in the onboarding doc.

Day 5 end: a 30-minute voice retro between founder/lead and engineer. Same five rating categories you've been logging all week, now reviewed together. Decide: keep the engineer for week 2, swap them, or end the engagement.

1-week vs 2-week vs month-long onboarding

Length	Best for	Day 1 milestone	End-of-program milestone	Risk
1 week	Startups, contract bookings, urgent staffing, AI-native engineers on small-to-mid codebases	PR opened by EOD	Shipped to prod by Friday	Codebase docs better be honest; no time to absorb tribal knowledge
2 weeks	Series A teams, hires onto teams of 5 to 15 engineers, codebases with 2 to 4 major services	Environment up day 1, first PR day 2 to 3	Owning a small feature area by EOW2	More forgiving but easy to slide into "ramp theater" if week 2 isn't scoped
1 month	Enterprise, regulated industries, large legacy codebases, full-time hires onto 30+ engineer teams	Onboarding cohort kickoff	Owning a project, on-call rotation	High cost if the hire isn't a fit; ramp cost often exceeds salary for the month

The honest read: a month-long onboarding is right when the codebase complexity, compliance burden, or team size genuinely require it. It's wrong when it's a habit inherited from in-office norms. We see plenty of 12-engineer startups running 4-week onboardings because that's what their last company did. They could halve it.

A one-week onboarding works specifically when the engineer is AI-native (so codebase exploration is faster), the codebase is reasonably documented, and someone on your side is going to actually respond to PRs inside 2 hours. Miss any of those and stretch to two weeks.

Where this fits with Cadence

If you've already booked an engineer through Cadence, the one-week onboarding maps cleanly onto the 48-hour free trial plus the rest of week 1. Day 1 and day 2 are the trial; you decide on day 3 whether to convert to a paid week. Every Cadence engineer is AI-native (Cursor, Claude, Copilot used daily), pre-vetted on async written communication and the discipline of treating prompts as specs, so the rhythm above is what they expect.

Cadence pricing tiers, for reference: junior $500/week (good for the test-coverage and integration tickets in your onboarding queue), mid $1,000/week (most general onboarding fits here), senior $1,500/week (owning the deploy and the architecture conversations), lead $2,000/week (fractional CTO, design decisions).

If you're booking specifically to test the one-week onboarding rhythm, mid at $1,000 is usually the right call.

Find a vetted engineer in 2 minutes, run the week-1 program above, and decide on Friday. 48-hour free trial, weekly billing, replace any week. Book through Cadence when you have your spec ready.

What to do this week

If you're reading this because you have an engineer starting Monday:

• Today: write the 5-line root README, scope the day 1 ticket, record the codebase Loom.
• Tomorrow: test the bootstrap script on a clean machine. Time it. Fix it if it takes over 15 minutes.
• Day before start: send the engineer the repo, the Loom, the ticket, and the Slack channel link. No surprise on Monday.
• Monday 9am: voice kickoff, then get out of their way.

If you're reading this because you're considering whether to even run a one-week onboarding: the answer is yes, assuming the engineer is AI-native and your codebase has any kind of README. The cost of trying it and failing is one week. The cost of defaulting to a month is, often, a month.

FAQ

Can you really onboard a senior engineer in one week?

Yes, if the codebase has even minimal docs and someone is responsive to PRs. Senior engineers are typically faster, not slower, in week 1 because they ask better questions and don't need handholding on the deploy pipeline. The bottleneck is almost always the host team's responsiveness, not the engineer's ramp speed.

What if our codebase is too complex for a one-week ramp?

Then either accept a two-week ramp or invest one week in writing the onboarding docs that would have made one week possible. Most "too complex" codebases aren't actually complex; they're under-documented. The fix is the same either way.

How do you handle timezone gaps during one-week onboarding?

Lean harder on Loom and written specs. The day 1 voice kickoff can happen in a 4-hour overlap window. After that, every artifact (PR description, ticket comment, async standup) is written so review happens whenever the other party is online. The 2-hour PR review SLA becomes "first business hour of the reviewer's day."

What if the engineer doesn't ship to prod by Friday?

Treat it as a signal. Either the ticket was wrong-sized, the review queue was slow, or the engineer is the wrong fit. Don't extend the week to save face. Use the Friday retro to decide which of those three it was and act on it. Weekly billing exists for exactly this reason; a swap on Monday costs you nothing.

Should onboarding be different for contract vs full-time hires?

In week 1, no. The schedule above works for both. The difference shows up in weeks 2 to 4, when full-time hires take on longer-term scope (on-call, project ownership, mentoring) that contract engineers usually don't. Use week 1 to prove the engineer can ship; use later weeks to decide what scope they own.