Ask a GCC vendor for their setup timeline and most will hand you a Gantt chart describing activity: entity formation in week two, recruitment starting week four, infrastructure by week eight. Activity is easy to schedule and hard to verify. What we track instead is evidence — the specific, checkable things that should exist by day 100, regardless of what activity produced them.
By day 30, the foundation should be checkable
Not "entity formation in progress" but a signed entity document or an active employer-of-record agreement. Not "office identified" but a signed facility agreement in a documented technology corridor. Not "recruitment starting" but a written recruitment brief that names your product context specifically enough that a candidate could describe what they would be building in their first week.
By day 60, the team should be real, not projected
Signed offers, not pipeline candidates. Systems access provisioned, not "in setup." And critically — the first product context session between your leadership and the India team should already have happened, not be scheduled for later. Teams that push context transfer past day 60 are the teams still explaining requirements from scratch in month four.
By day 100, the evidence is a shipped sprint
Not a demo. Not a plan for the next sprint. A sprint that shipped, with velocity measured against a baseline, and a written summary that goes to your board describing what actually happened — including what did not go to plan, if something did not. A 100-day report with no caveats in it is not a report. It is marketing.
Why evidence beats activity
The value of tracking evidence instead of activity is that it cannot drift silently. An activity-based timeline can slip by a week at a time, quietly, with each slip individually defensible. An evidence-based checkpoint either exists or it does not on the date it was promised — which is exactly the accountability a board wants and a vendor rarely offers voluntarily.