What to Hand an External Product Team on Day One

Most delays in the first month of an external engagement are not caused by the code. They are caused by waiting for an account, a credential, a decision or a person. The team is being paid throughout, and the delay is invisible because nothing looks wrong from either side.

This is the day-one list, written from the receiving end: what an external team actually needs, what each missing item costs in practice, and the two things you should not hand over.

Key takeaways

• Access is the schedule: Most first-month slippage is waiting for credentials.
• A named decision-maker matters more than documentation: Questions arrive daily in week one.
• Prepare the list before the contract is signed: Half of it needs your own internal approvals.
• Two things stay with you: Production write access and customer data you do not need to share.

The eight things

1. Read access to the relevant code

The repository, with history. If the new product connects to an existing system, they need to read that system rather than have it described. Missing: scoping runs on meetings, which consumes your engineers.

2. The database schema, and a realistic sample of data

Structure is not enough. Real data reveals what the schema hides: the fields used for something other than their name suggests, the inconsistent values, the assumptions that turned out not to hold. Anonymised is fine and usually better. Missing: problems surface in week six that could have surfaced in week one.

3. A named decision-maker for the interface

One person, reachable within a day, who can answer what the new product may read and write. Not a committee. In the first two weeks these questions arrive daily; after that they thin out to a few a month. Missing: the team either waits or guesses, and guessing is worse.

4. The environments and credentials they need

Test accounts for every third-party service involved: payments, messaging, maps, whatever the product touches. These often need procurement or a supplier's approval, which is slow and is the single most common cause of a stalled first month. Start this before the contract is signed.

5. The business outcome in your own words

One or two sentences about the change you want in the business, not the software you want built. Every scope decision refers back to it.

6. Constraints that are not negotiable

Regulatory requirements, a platform you must integrate with, a technology standard, a date that exists for a real reason. Say these on day one. Discovering them in week six is what makes scope get redone.

7. Access to real users

An hour with three people who will actually use the thing is worth more than a month of specification. This is also the item most often promised and least often delivered.

8. How you want it to end

Whether your team takes it over, the external team keeps running it, or it merges into your system later. This changes technology choices, documentation standards and conventions from the first week. Deciding it late is how teams inherit something they cannot maintain. We cover it in who owns the new product after it ships.

The two things to withhold

Write access to production. There is almost never a good reason for an external team building a separate product to write directly to your live system. If they need to change data, it goes through an interface you control. This is the boundary that keeps the arrangement safe.

Customer data you do not need to share. Anonymised or synthetic data answers almost every development question. Share real personal data only where there is a specific reason, and where your own obligations allow it.

The cost of getting this wrong

Almost all of it is procurement and permissions rather than engineering, which means it can be done in parallel with contracting instead of after it.