What should an outsourced technical partner deliver in week one?

Most failed outsourcing relationships were already failing in week one. The vendor was still gathering requirements, the client was still explaining context, and nobody had written down what success would look like in a number. Three months later the disagreement is about scope, but the cause is that first week.

So the useful question to ask any partner before signing is not what their rate is. It is: what will I be holding seven days after we start?

1. A bottleneck map. One page, ranked, naming the constraint that is actually holding the product back. Not a list of everything that could be improved. A constraint has a property a wish list does not: fixing it changes an outcome you can measure.

2. One success metric. Release cycle time, crash free sessions, field failure rate, cost per device, time to first successful integration. One number, agreed by both sides, that decides whether this worked. If a partner resists naming it, they are protecting themselves from being measured.

3. Access you can use without asking. A staging URL, a repository, a dashboard. Visibility should not require a status meeting. When a client has to request a demo to know what happened, the relationship has already become a performance.

What would you need to see in our codebase before quoting?

If this goes well, what will be different in ninety days, in numbers?

What does handover look like, and what does it cost?

What has gone wrong on a recent engagement, and what did you change after?

A good partner should be willing to tell you that you do not need them yet. If the diagnosis says your constraint is hiring, or pricing, or a product decision nobody has made, that is a more valuable week one than a proposal would have been.

If you are evaluating partners right now, the diagnosis call covers exactly this and costs nothing.