What should the first two weeks of a software project produce?

They should produce one narrow path deployed to a real environment, the first set of automated checks written before the code they describe, a written list of named unknowns with decision dates, and a rollback that somebody has actually performed. Documents and designs can accompany these, but on their own they prove nothing about whether the project can ship.

Why deploy something in week one when there is nothing to show?

Because deployment is where the expensive surprises live, and finding them in week one costs a conversation while finding them in week seven costs the schedule. Credentials, network rules, security review, third-party access and environment differences are all discovered by trying, and none of them appear in a design document.

What is a thin slice and why does it matter?

A thin slice is the narrowest complete path through the whole system: a request from a browser, through authentication, into the database, and back with a rendered result. It is deliberately not a feature. Its purpose is to exercise every layer and every boundary once, so that the parts nobody estimated get discovered before anything depends on them.

Should design be finished before development starts?

Design does not need to be finished, it needs to be far enough ahead that the next slice of work is unambiguous. Finishing all design before any deployment means every design decision is made without evidence from the running system, and the decisions that turn out to be wrong are the ones that have already been drawn into twenty other screens.

How many requirements should be specified in the first two weeks?

Specify the first one or two properly rather than all of them loosely. A single requirement turned into checks a machine can run will teach you more about the gaps in the brief than a full backlog of one-line stories, because it forces every vague sentence to be decided while deciding is still cheap.

What are the warning signs in the first two weeks?

The clearest ones are that nothing has been deployed, that no unknowns have been written down, that every question gets a confident answer with no evidence behind it, and that the team cannot name who decides when two stakeholders disagree. Each of these is survivable alone and each gets much more expensive the longer it runs.

Who needs to be involved in the opening fortnight?

Whoever can answer questions about correct behaviour without escalating, plus whoever controls access to the environments, the data, and any third-party systems. Access is the part that gets forgotten, and a project can lose a week waiting for a credential that nobody was assigned to request.

How do you handle a client who wants to see features instead?

Show the deployed thin slice and explain what it proved. It is genuinely less impressive than a set of polished screens, and it is a far better predictor of whether the project ships on time. Most stakeholders accept this readily once they have seen a project fail the other way.

What does a good rollback plan look like at this stage?

It looks like a procedure somebody has run at least once against the real environment, with the time it took written down. An untested rollback plan is a document expressing hope. The first two weeks are the cheapest moment in the entire project to test one, because there is nothing valuable to lose yet.

Is two weeks the right length for this phase?

Two weeks is a useful default because it is long enough to deploy and specify something real and short enough to force decisions. The duration matters much less than the deliverables, and a project that reaches those four outcomes in six days should move on rather than spending the remaining time producing documents to fill the box.

What belongs in the first two weeks of a software build: Reveneau

Every software project has a fortnight that decides more than the ten that follow. It is the first one, and the reason is simple: it is the last period where changing course costs a conversation instead of a rewrite.

Most teams spend it on the wrong things. Not through carelessness. The wrong things are genuinely more comfortable, they look like progress to everyone watching, and the bill for choosing them does not arrive until week seven.

The fortnight that feels productive and proves nothing

The common version goes like this. Week one is kickoff, stakeholder interviews, a review of the existing system, and an architecture discussion. Week two is wireframes, a groomed backlog, and a plan. There is a deck at the end. Everybody is pleased.

Nothing has run. Nothing has been deployed. No requirement has been specified precisely enough that two people would agree on whether it was met.

Then in week seven, the first real deployment turns out to need a security review the client's own infrastructure team schedules three weeks out. Or the third-party API the entire integration depends on only issues credentials to a registered corporate entity, and the registration takes a month. Or the database that the design assumed has 400,000 rows of customer data has 11 million, and a third of them have a null in a field the schema says is required.

None of these are exotic. They are ordinary, and they are all discovered by trying, which is precisely what a fortnight of documents avoids doing.

Four things the first two weeks should produce

1. One thin path, deployed where it will actually run

Not a feature. A thin slice: the narrowest complete path through every layer of the system. A request from a browser, through authentication, into the database, back out, rendered on screen. Something trivial. A page that displays the logged-in user's own name is enough.

It looks like almost nothing. It exercises the build pipeline, the deployment process, the environment configuration, the secrets management, the authentication provider, the database connection, the network rules, and the monitoring, all once. Every one of those is a place a project loses days, and none of them appear on a backlog because nobody thinks of them as work.

Deploy it to the environment the software will genuinely live in, not to a local machine and not to a sandbox that nobody has to approve. The approval is the part you are testing.

2. The first requirement, written as checks

Take one real requirement, ideally the one the client cares most about, and turn it into statements a machine can verify. Write the checks first, watch them fail, and leave them failing.

This is the cheapest possible way to find out which sentences in the brief nobody had actually decided. It happens every time. "Users can invite team members" survives a kickoff, a design review, and a signed statement of work, and then dissolves the moment you try to write the check: can an invited user invite others, what happens if the email already belongs to another account, does an expired invitation reactivate or regenerate, who can revoke.

Those questions have answers. They are just answers nobody had given yet, and getting them in week one costs an email. Getting them in week seven costs the two screens and the database table that were built on a guess. The method is set out in more detail in adding eval tests was the best decision we made.

3. The named unknowns, with decision dates

Every project has three or four things nobody can know yet. The data quality in the legacy system. Whether the compliance requirement applies to this product. What the partner API does under load. Whether the client's own security team will approve the architecture.

Write them down as a list. Against each one: who can answer it, what happens to the plan under each possible answer, and the date past which not knowing starts costing money.

The list has a second job, which is political. When an unknown resolves badly in month three, the difference between a difficult conversation and a broken relationship is entirely whether the risk was on a shared page in week one.

4. A rollback that somebody has performed

Deploy the thin slice, then roll it back, then deploy it again. Write down how long each took.

Nearly every project has a rollback plan and nearly none of them have been executed. An untested rollback is a document expressing hope. The first fortnight is the cheapest moment in the entire project to test one, because there is nothing valuable in production yet to lose. Wait until there is, and the first rehearsal becomes the first real incident. What a rollback plan looks like for AI-written features goes deeper on this.

Why deployment beats design in week one

The objection is reasonable: a thin slice looks like nothing, and a set of polished screens looks like a project. Stakeholders who have paid money would rather see the screens.

The argument to make is about where the risk sits. Design risk is real, and it is recoverable. A screen that turns out to be wrong gets redesigned, and the cost is roughly the cost of drawing it again. Integration and environment risk is not recoverable in the same way, because it has a queue attached: somebody else's security team, somebody else's API onboarding, somebody else's procurement process. You cannot compress a three-week approval window by working harder on it.

So the sequence that minimises total risk is to hit the things with external dependencies first, while there is still slack in the schedule to absorb them. Design proceeds in parallel. It just does not block the deployment.

What good looks like at the end of day ten

A short and unglamorous checklist.

Something is running in the real environment, and it was deployed by a pipeline rather than by hand. Somebody other than the person who built it has rolled it back and put it back. There is a written list of things that must be true about the first feature, expressed as failing checks. There is a written list of unknowns with dates. There is a named person who decides when two stakeholders want different things, and everybody knows who it is.

Notice what is not on the list. Not a complete backlog, not a finished architecture diagram, not a design system, not a velocity estimate. Those are all fine to have and none of them tell you whether the project can ship.

The signals that predict the rest

Three things visible in the opening fortnight correlate strongly with how the project ends.

Whether anything surprised you. A fortnight with no surprises is an unrevealing one. Surprises arrive on a fixed schedule regardless of when you look for them; only the price changes.

How questions get answered. A client who says "I will find out and come back to you tomorrow" is a better sign than one who answers everything immediately. Confident answers with nothing behind them are the raw material of week-nine rework.

Whether the team can say no. A team that accepts every request in the first two weeks without pushing back on any of them is deferring a conflict to a point where it will be more expensive. We wrote about the mechanics of this in how to say no to a feature request.

The trade nobody states out loud

Spending the first fortnight on deployment and specification means the client sees less in the first demo. That is a genuine cost and it is worth being honest about it rather than pretending the thin slice is exciting.

What they get in exchange is that the surprises land in week one, when the plan can absorb them, instead of in week seven, when it cannot. Every project finds out what it did not know. The only variable is whether it finds out while the finding is still cheap.

Sources

2025 DORA report announcement, Google Cloud: drawn from roughly 5,000 respondents; deployment frequency and recovery time remain the practices that separate high performers.
METR, early-2025 study of experienced open-source developers: 16 developers took 19 percent longer on 246 tasks with AI tools while believing they had been 20 percent faster, which is why early estimates deserve evidence rather than confidence.