Short answer
Day one is alignment rather than introductions: communication channels and response times, who on the client side can approve scope and designs, meeting cadence, how blockers get handled, and the client describing success in their own words, all closed out in a one-page working agreement sent in writing that afternoon. Days two and three are technical discovery and environment setup, where every "this should be simple to connect to" assumption from the proposal gets tested against reality, ending in a written technical findings note. Day four produces a first-draft architecture covering the core data model, the major components and how they interact, external dependencies, and recommended technology choices with reasoning, reviewed together with the client. By Friday there is code in a repository, a staging environment standing up, and one small working piece of the system; if all of week one was meetings and documents, something went wrong.
Week one of a software engagement sets the tone for everything that follows. We have shipped enough projects to recognize, usually by Wednesday of the first week, whether the engagement is set up for a clean run or whether we are about to spend months managing a problem that started at the beginning.
Here is what a great kickoff week looks like. Specific rituals, specific deliverables, and the red flags we watch for when week one is going wrong.
Day One: Alignment, Not Introductions
The kickoff meeting is not a project review. It should not be a tour of the proposal. Everyone on both sides has read the materials. The kickoff meeting is for aligning on working agreements before they are needed.
What we cover on day one: communication channels and response time expectations, decision-making authority on the client side (who can approve scope changes, who can approve designs, who has veto power), meeting cadence, how we handle blockers, and the process for scope changes.
We also do one specific exercise: we ask the client to describe, in their own words, what success looks like at the end of the engagement. Not what they want to build - what success looks like. If the answer is significantly different from what we understood from the brief, that is useful information to have on day one rather than week eight.
The deliverable for day one: a one-page working agreement document, reviewed and agreed verbally, then sent to the client in writing that afternoon.
Day Two and Three: Technical Discovery and Environment Setup
The brief describes the problem. Day two and three are for understanding the technical context in enough detail to start building.
This includes: an audit of any existing systems the build needs to integrate with, access provisioning for environments we will need, a review of any data the client is providing, and a first look at the production environment requirements.
We try to surface integration surprises early. Every "this should be simple to connect to" assumption from the proposal gets tested against reality. External APIs that the brief assumed were well-documented sometimes are not. Data exports that the brief assumed were clean sometimes have gaps. Better to find out on day two than week four.
The deliverable for day two and three: a technical findings note - a short written document that confirms our understanding of the technical landscape, flags any surprises we found, and updates the build plan if anything changed.
Day Four: First Draft of the Architecture
By day four we have enough context to draft the application architecture. Not a final architecture - a first draft that can be reviewed, questioned, and adjusted. The point is to make the architectural decisions visible before they are embedded in code.
We document: the core data model, the major system components and how they interact, the external dependencies, and the technology choices we are recommending with brief reasoning for each choice.
This document is sent to the client and reviewed together. Clients do not need to understand every technical decision, but they should understand the shape of the system. When the architecture is made visible, clients sometimes surface constraints or requirements that were not in the brief. Better now than later.
Day Five: Work Actually Starts
By Friday of the first week, there should be code in a repository, a staging environment standing up, and the first concrete task in progress. If all of week one was meetings and documents, something went wrong.
The Friday output is simple: one working piece of the system - even a small one. Not a complete feature, but something that demonstrates the basic architecture is functional and the team is building in the right direction.
The Red Flags We Watch For
Three signs in week one that the engagement is in trouble.
The scope starts shifting before the build does. If the client is adding requirements in the kickoff week, the brief was not solid enough to build from. We stop and go back to scoping before we write more code.
Access is not ready. If we cannot get into the systems we need by the end of day three, the timeline is already slipping. We escalate this immediately rather than waiting.
The key stakeholder is not available. Every custom software project kickoff has a person on the client side whose judgment is essential. If that person is not meaningfully available in week one, decisions get deferred and the build starts in uncertain territory.
A strong kickoff week does not guarantee a smooth project. But a weak kickoff week reliably predicts a difficult one.
If you are planning a build and want to talk through what your week one should look like, we are happy to help structure it.
Questions · 04
Frequently asked questions
How do I know if my kickoff week is going badly?
Three signs. Scope starts shifting before the build does, which means the brief was not solid enough to build from and scoping needs to reopen. Access to the systems the team needs is not ready by the end of day three, which means the timeline is already slipping. Or the stakeholder whose judgment the project depends on is not meaningfully available, which defers decisions and starts the build in uncertain territory.
Why ask the client what success looks like when there is already a brief?
Because describing success is a different exercise from describing what you want to build. If the answer comes back significantly different from what we understood from the brief, that is information worth having on day one rather than in week eight.
Does the client need to understand the architecture document?
Not every technical decision, but they should understand the shape of the system. The point of drafting it in week one is to make architectural decisions visible before they are embedded in code, and clients reviewing it often surface constraints or requirements that were never in the brief.
Does a strong kickoff week guarantee the project goes well?
A strong kickoff week does not guarantee a smooth project. A weak one, though, reliably predicts a difficult one, which is why the first five days are worth structuring deliberately instead of filling with introductions and a walkthrough of the proposal.
