Overflow Development Capacity in 48 Hours: A Partner Onboarding Protocol

Overflow development capacity is only real once the partner's first reviewed change is merged into your repository. Until then, you've added a contract and a cost, not capacity.

The fastest honest way to get there is a 48-hour protocol with four blocks: access, repo conventions, written standards and one real ticket. It ends with a pass/fail test you can check yourself.

An overflow development partner is an outside team that builds work your agency has sold but can't staff, usually under your name. This guide is written for the delivery lead who has sold more work than the team can build. It's partner-agnostic, so you can hand it to any overflow partner, including one you already use.

What should a 48-hour onboarding achieve?

A 48-hour onboarding should end with one merged, reviewed pull request on a real ticket, shipped through your pipeline, with no shared passwords anywhere. That single outcome proves access works, conventions are understood and review runs in both directions.

Forty-eight hours is short on purpose. It's long enough to touch every part of your delivery path and short enough to fail cheaply. The old lesson from Fred Brooks's The Mythical Man-Month (1975) still applies. Adding people to a late project makes it later, because new people cost lead time before they add output. A tight protocol keeps that cost small and visible.

The protocol runs in four blocks:

1. Hours 0-4: access
2. Hours 4-12: repo conventions and local setup
3. Hours 12-24: standards and definition of done
4. Hours 24-48: first ticket to merged pull request

Before hour zero, the agency needs three things ready. You need a chosen ticket, a named reviewer on your side with time blocked, and a one-page conventions file in the repository. If any of those is missing, start the clock later rather than burn the partner's first day.

If you haven't vetted the partner yet, do that first. Vetting an offshore development partner is a separate job, and this protocol assumes it's done.

Hours 0-4: What access should the partner get first?

Give the partner named, individual seats inside your own organization, with the least privilege that lets them ship one ticket. Nothing shared, nothing in their accounts, and nothing you can't revoke in an afternoon.

This isn't paranoia. Verizon's 2025 Data Breach Investigations Report found that the share of breaches involving a third party doubled, from 15% to 30% (Verizon DBIR, 2025). That figure covers every kind of third party, from software vendors to partners. Leaked secrets are a frequent weak point. GitGuardian's State of Secrets Sprawl 2026 found internal repositories roughly six times more likely than public ones to contain hardcoded secrets (GitGuardian, 2026).

The same Verizon report found that leaked secrets discovered in a GitHub repository took a median of 94 days to fix (Verizon DBIR, 2025). A secret that leaks during onboarding can stay usable for months, so the first four hours cover this list:

• Source control: individual accounts added to your organization, write access to branches only, main protected with required review and passing CI, no admin rights
• Issue tracker: access to one project, not the whole workspace
• Chat: one shared channel for the engagement, not guest access to every channel
• Environments: staging only; no production access and no production data
• Secrets: a secrets manager or a vault entry per environment, never a pasted value in chat, email or the repo
• Client contact: none yet; the client relationship stays with you

Write the offboarding steps now, while you're granting access. If revoking everything takes more than one afternoon, the access model is too loose. The code, the pipeline and the cloud accounts should stay yours throughout, which is the ownership point covered in who owns the code a partner writes.

Hours 4-12: How do you hand over repo conventions?

Hand over repo conventions as a short written file in the repository, then have the partner prove local setup works. A walkthrough call helps, but a call is forgotten by the second ticket and a file is not.

The conventions file should fit on one page. It covers:

• Branch naming: for example feat/<ticket-id>-short-name
• Commit format: whatever you already use, with one example
• Pull request template: what changed, how to test, screenshots for UI work, linked ticket
• Lint and format rules: enforced in CI, so nobody argues style in review
• Local setup: one script or a short numbered list that works on a clean machine
• Environment variables: an example file listing names only, never values
• Tests: the one command that runs them, and which ones must pass before a PR opens

Then set the first check. The partner runs the app locally and posts the test command's output and a screenshot in the shared channel. If that takes longer than a few hours, check for undocumented setup on your side first. Fix the file, not the partner.

Timing matters here too. If your team and the partner work across time zones, agree when handoff notes are written and when questions get answered. The trade-offs are covered in overlap hours in offshore work.

Hours 12-24: What standards will the code be judged against?

The partner's code should be judged against a written definition of done that your lead can check in review, agreed before the first ticket starts. If the standard only exists in a reviewer's head, the first pull request becomes a negotiation.

A workable definition of done for a React and TypeScript codebase looks like this:

• Strict TypeScript, with no unexplained any or @ts-ignore
• Tests on anything touching money, authentication or personal data
• No new lint warnings, and CI green before review is requested
• Basic accessibility: labeled inputs, keyboard focus that works, alt text on images
• The pull request stays small and does one thing

Small matters. In Google's published study of its own code review, the median change modified 24 lines. Small changes got first feedback in a median of under an hour (Sadowski et al., ICSE-SEIP, 2018). Fewer than 25% of changes there had more than one reviewer. Small pull requests with one named reviewer keep review fast, which is exactly what an onboarding week needs.

Review speed is a standard for you as well. Agree a turnaround, such as review within one working day of the pull request opening. A partner waiting two days for comments is paid capacity sitting idle.

A common failure mode is two standards. The partner writes code to one, the agency reviews against another, and both think the other is slow. If you'd like a second opinion on your definition of done before a partner starts, a free 30-minute scoping call with us is one option.

Hours 24-48: What makes a good first ticket?

A good first ticket is real, small and low-risk, and it touches the whole delivery path: code, test, pull request, CI, review and a staging deploy. It should also be something you've already estimated, so the result tells you something.

The estimate is the point. Your first tickets give you a calibration ratio: the partner's logged hours divided by your team's estimate for the same work. That ratio is the most honest input you'll have for committing a client deadline to a new partner.

Here's a worked example with illustrative numbers, not data from a real engagement. Your team estimates three starter tickets at 4, 6 and 10 hours, a total of 20. The partner logs 5, 8 and 13 hours, a total of 26.

The ratio is 26 ÷ 20 = 1.3. A client scope your team estimates at 60 hours should be planned at 60 × 1.3 = 78 hours of partner time, plus your own review time. If you'd quoted the client on 60, you'd be 18 hours short before anything went wrong.

One ticket is enough to pass the 48-hour test, but not enough to trust the ratio. Keep tracking it for at least the first month. The ratio usually moves as the partner learns the codebase, and you want to see which way.

How do you know the partner passed?

The partner passed if, at hour 48, you can tick every item below without asking for anything extra. A pass means you can start assigning client work. It doesn't yet mean you can promise client dates.

• To do: One pull request merged into main through your normal review
• To do: CI green, with no rules skipped or disabled
• To do: Conventions followed without reminders: branch name, commit format, PR template
• To do: Questions asked in writing, in the shared channel
• To do: The change is running on staging
• To do: Hours logged against the ticket and the first calibration ratio recorded
• To do: No secret shared outside the secrets manager

If the partner fails, look at your own side first. Was the ticket clear? Did setup work on a clean machine? Did your reviewer respond within the agreed time? Fix what's yours and run the 48 hours once more. If the same gaps appear on a well-prepared second run, you've learned something useful for the price of two days.

For the commercial side of this model, including margins and rework, see the economics of white-label React work.

When is a 48-hour onboarding the wrong approach?

A 48-hour onboarding is the wrong tool when the work can't be separated, when the codebase can't support outside contributors, or when the capacity gap isn't really overflow.

Skip it, or fix the underlying problem first, in these cases:

• The work isn't separable. If every ticket needs a long conversation with your lead, a partner adds coordination cost, not capacity.
• There's no CI and no tests. Without automated checks, your reviewer becomes the only quality gate. The first week turns into manual testing.
• The client contract forbids subcontracting. Many client contracts require consent before work is subcontracted, so check the paper before anyone gets a seat.
• The gap is permanent. If you've needed extra hands every month for a year, that's a hiring or team-structure decision, and a longer engagement model may fit better.
• The deadline is this week. A new partner won't rescue a date that's already slipping. Onboarding costs your lead's time first.

If you're weighing offshore capacity more broadly, our offshore development page covers how we approach it.

Frequently asked questions

Start with one ticket

Overflow capacity isn't bought when the contract is signed. It's earned in the first 48 hours, when access, conventions, standards and one real ticket all work together. Run the protocol, record the ratio, and only then put a client date on it.