We have done enough projects now to know that the first two weeks are diagnostic. Very little of the product exists yet, but almost everything about how the engagement will go is already visible if you know where to look.
Can we get access to things
The first week is mostly requests: a repository, a staging environment, API keys for the services you already use, a contact who can answer questions about the existing data. On a project that is going to go well, most of that arrives within a day or two. On a project that is going to be painful, week one ends with half of it still "being sorted out with IT".
This is not about blame. It is a signal about how much friction sits between a decision and it happening on your side, and that friction does not go away once the build starts — it just gets more expensive.
Who answers a question, and how fast
During the first fortnight we will have a lot of small questions. Should this field be required. What happens to an order in this edge case. Which of these two behaviours is the one you actually want.
If those get answered in hours by someone who knows, the project has a working decision-maker and it will move at a predictable pace. If they get answered in days, or bounce between three people, or come back as "whatever you think is best" on questions that are actually about your business, we adjust our expectations about the timeline immediately.
Did the plan survive contact
We start every project by scoping the areas we flagged as uncertain in the estimate. By the end of week two we know whether those unknowns resolved the way we hoped or whether one of them just got bigger.
Finding that out early is the entire point. A nasty surprise in week two costs a conversation and a revised plan. The same surprise in week ten costs rework, a slipped date, and a difficult invoice.
What we do with the signal
If the first two weeks go smoothly, we say so, and we hold the plan.
If they don't, we raise it directly — not at the end, when it is a post-mortem, but now, when it is still a course correction. Usually that means naming the specific friction (access, decisions, an unknown that grew) and agreeing what changes. Sometimes it means revising the estimate while the revision is still small.
The projects that go badly are almost never the ones where something went wrong in week two. They are the ones where something went wrong in week two and nobody said anything until week eight.