Ask any founder who’s hired an outside dev team a simple question: what happened in the two weeks after you signed the contract? Most can’t answer precisely. There was a kickoff call. Someone set up a Slack channel. A project manager sent a “we’re excited to get started!” email. And then, quietly, three or four weeks passed before anyone actually wrote code that shipped. That gap has a cost, and almost nobody prices it into the deal.
The pitch process sells you on rates and delivery dates. It rarely mentions that the clock on “delivery” usually doesn’t start ticking until the team has actually understood your codebase, your environment, and your product well enough to build something correct. If that understanding-gathering step is unstructured, it eats into the timeline you were quoted — and you find out only when the first sprint demo is thinner than you expected.
Why the gap exists
Two weeks is not an accident of scheduling. It’s usually the time it takes for a new team to:
- Get access to repos, cloud accounts, API keys, and design files — which often requires chasing down whoever originally set them up, including a previous contractor who’s no longer responsive.
- Actually read the existing code, if there is any, and figure out what’s real versus what’s scaffolding left over from an MVP or a hackathon weekend.
- Reconcile what the founder thinks the product does with what the product actually does. These are rarely the same thing after six months of ad hoc changes.
- Set up local environments, CI, and a staging target that mirrors production closely enough to trust.
None of this is glamorous, so it’s easy for an agency to gloss over it in a proposal. But skip it or rush it, and the team starts writing code against a wrong mental model — which shows up four weeks later as rework, not as a delay you can point to in real time.
What a real handoff should produce
A handoff isn’t “we’re getting oriented.” It should be a concrete, inspectable process with outputs you can check against, not a vibe. At a minimum, the first two weeks should produce:
- A written scope reconciliation. Not the sales-stage scope — an updated one, after someone with engineering judgment has actually looked at your existing code or your product spec and flagged what’s missing, ambiguous, or harder than it looked from the outside.
- A runnable environment. If there’s an existing codebase, it should build and run locally, with the steps documented, before anyone touches a feature. If it doesn’t build cleanly, that’s information you need on day three, not day thirty.
- An honest audit note, if there’s legacy code. What’s solid, what’s fragile, what’s a security concern, what will need to be rebuilt rather than extended. This should be specific — file names, patterns, dependencies — not “the codebase has some technical debt.”
- A first commit that’s real work, not busywork. Setting up linting and CI counts as infrastructure, not stalling — but by the end of week two you should see a commit that touches actual product logic, even something small, so you have proof the team is inside the system and not just around it.
The common thread is specificity. Vague status updates (“still getting up to speed”) are the tell that the handoff is unstructured. A team that’s actually doing the work can point to what they found and what they changed because of it.
What founders typically get instead
In practice, a lot of engagements — especially with larger agencies staffing junior developers under a account manager — spend the first two weeks on internal ramp-up that never surfaces to the client: developers reading Confluence docs, project managers building Jira boards, and a kickoff deck that restates the pitch. The founder sees activity in the form of meetings, not code. By the time real building starts, a third of the first month’s budget is already spent, and the delivery date hasn’t moved to reflect it.
This is also where the difference between a freelancer, a large agency, and a small senior team tends to show up most clearly. A freelancer may skip structured handoff entirely and just start coding against assumptions — fast, but risky if those assumptions are wrong. A large agency often has the process but buries it in overhead and account-management layers, so you’re paying for coordination as much as construction. The version worth paying for is a small team senior enough to do the audit themselves, in days, and blunt enough to tell you what they actually found — including if the existing code needs to be partly rebuilt rather than extended.
What to ask before you sign
If you’re evaluating a dev partner, ask them directly: what will you deliver in the first two weeks, and can I see it? A team confident in its process will give you specifics — an environment, a document, a commit — not a schedule of check-in calls. If the answer is vague, assume the gap will cost you a chunk of your first month, whether or not it’s visible in the invoice.
This is close to how we run things at orithLabs — we’ve done this handoff on our own shipped apps like Crumb Count and Kompete, and on code audits where the first real deliverable was a plainly worded list of what was solid and what wasn’t. If you’re mid-negotiation with a studio, or trying to figure out why a build has stalled, it’s worth asking to see what their first two weeks actually look like on paper.