What We Need From You to Start

Less than you think, but at the right moments

Clients routinely over-prepare in the wrong direction: a long requirements document written in isolation, and no arrangement for the API credentials we will need on day three. The document is useful; the credentials are what decide whether week one is productive.

The list below is short on purpose. Everything on it is something only you can provide, and each item has a real cost attached to arriving late.

1. One person who can decide

Not a committee, and not someone who has to seek approval for every scope question. The single strongest predictor of a project finishing on time is a client-side decision-maker who can answer a scope question within 48 hours.

If decisions genuinely require a committee, that is workable — but tell us at kick-off so we batch questions into a fortnightly decision session rather than blocking on each one.

2. Access, arranged before day one

• API credentials for every system in the integration list
• A staging or sandbox environment where one exists
• Read access to the database we are migrating from
• Whoever administers your domain and DNS, for launch
• Any VPN or network access an internal system needs

This is the item that most often costs a fortnight, and almost never because anyone objected. It goes slowly because it involves a third party, or an IT policy, or a person on leave. Start it the day you sign, not the day we ask.

3. Real data, not a tidy example

We need a sample of the actual data, with the inconsistencies intact. Anonymise it if you must, but do not clean it — the mess is the information. A tidy example teaches us nothing about the 4% of records that will break the import.

Every data migration we have ever run took longer than the client expected, and in every case the reason was visible in the first thousand real rows.

A thousand genuine rows is worth more than a perfect specification of what the data is supposed to look like.

4. Two hours a week, predictably

One demo, one round of feedback. That is the whole commitment in a normal week. What causes damage is not the volume but the unpredictability — three weeks of silence followed by an urgent reversal of a decision made a month earlier.

If you are going to be unavailable, tell us in advance and we will sequence the work to avoid needing you. That is easy with notice and impossible without it.

What happens when something is late

We flag every one of these in the twice-weekly update with a date attached, so nothing becomes a surprise at the milestone.

What you do not need to prepare

You do not need a technical specification, wireframes, a chosen stack, or a database design. Those are our job and doing them yourself before discovery usually costs money rather than saving it, because they encode assumptions we would want to test.

You also do not need finished content. Placeholder text is fine until the last sprint, and waiting for perfect copy is a common way to delay a launch by six weeks for no benefit.

Frequently asked questions