The First 30 Days with an Outsourcing Partner

The first 30 days after you sign with an outsourcing partner tell you more about the engagement than the pitch deck did. A vendor's sales process is optimized to sound good; onboarding is where you find out whether the delivery process actually is. Plenty of that gap is checkable before you ever sign, but the first 30 days is where whatever wasn't checked becomes visible anyway.

Week one: discovery, scoping, and access

A good first week is unglamorous and mostly logistics, and that's the point. The partner should run a discovery session that goes deeper than the sales conversation did — pulling apart your existing codebase or product requirements, surfacing constraints nobody mentioned in the proposal, and turning that into a written scope for the first sprint. If discovery produces the same generalities as the pitch, the team hasn't actually looked at your problem yet — often the first sign of a team without real domain fluency rather than one that's simply moving slowly.

Access setup belongs in week one too, not week two or "once we're rolling." Repository access, staging environment credentials, ticket tracker seats, a shared Slack or Teams channel — these should be provisioned before the first line of code is written, because a team that can't reach your systems can't be building on them. If you're still emailing credentials back and forth by day five, that's not a minor friction; it's the first real signal about how this partner operates.

By the end of week one you should have a named engineering lead, a scoped sprint one backlog, and a communication cadence on the calendar — this partner's own version of a service-level agreement for how the engagement runs, not just what it delivers. If any of those three is missing, ask for it directly rather than assuming it'll show up once things "settle in."

The first sprint: what running actually means

The first sprint is the only claim in the entire engagement that gets tested against reality within two weeks, so it's worth paying attention to. A good partner ends sprint one with something that runs — a deployed environment, a working slice of the feature, a passing test suite against real code — even if the scope is deliberately small — the milestone a properly structured contract should have already defined as done. The point isn't the size of the output; it's that the output exists and you can look at it.

What should worry you is a sprint that ends in a status update instead of a build. "We made good progress on the architecture" is not a deliverable, and a team that's actually writing code has commits, pull requests, and a branch you could check out if you wanted to. If none of that exists by the end of sprint one, the team either isn't staffed the way you were told, or the scoping in week one was too vague to execute against — both are worth raising immediately, not waiting out.

Watch the shape of the questions coming back from the team, too. A team that's actually building will ask specific things: which field is the source of truth when two systems disagree, what should happen on a particular error state, whether a given edge case is in scope. Those questions mean someone opened the problem up and hit a real decision point. Generic questions, or no questions at all, usually mean the work hasn't started in earnest.

Communication: who you should actually be talking to

Every outsourcing engagement has an account manager, and that's fine — someone needs to own the commercial relationship. The problem starts when the account manager becomes the only channel to the team doing the work, because now every technical question passes through someone who wasn't in the room when the decision was made. Information degrades with each handoff, and by the time it reaches you, "we're not sure this approach handles the refund flow correctly" has become "everything's on track."

A well-run engagement gives you direct access to the engineering lead, at minimum, and ideally a standing slot on the daily or weekly stand-up where the actual builders talk about what they built. You don't need to sit in on every standup, but you should be able to ask an engineer a technical question and get an engineer's answer, not a paraphrase filtered through someone whose job is to keep you happy rather than informed.

Cadence matters as much as access. A short async update a few times a week, plus a real sync at the end of each sprint, beats a single glossy report at the end of the month — the report can be written regardless of how the work actually went, but a team that's talking to you continuously has nowhere to hide a stalled sprint.

The first demo: credible versus hollow

The first demo is where all of the above either gets confirmed or falls apart. A credible demo is someone sharing their screen and clicking through a real, running feature — including what happens when you enter bad input, hit a permission boundary, or trigger the case that doesn't work yet. A team that shows you the failure cases along with the successes is a team that already knows where the rough edges are, which is exactly what you want this early.

A hollow demo looks like a roadmap slide, a set of mockups presented as if they were progress, or a screen recording with no live interaction at all. None of those are wrong to include in a broader update, but none of them are a substitute for something you can watch respond to input in real time. If sprint one's demo is entirely words and pictures, ask directly what's actually running, and don't accept "we'll have something to show next time" as the answer twice in a row.

If the first month looks like this — real access on day one, a working build by the end of sprint one, engineers you can talk to directly, and a demo that survives you asking to see the edge case — you're working with a team that delivers the way it says it does. If you're evaluating a partner right now and want to know what our own onboarding looks like in practice, get in touch and we'll walk you through it.