What to Build in Week One

The question "what should we build in week one?" sounds tactical. It's actually strategic. The answer shapes the entire arc of the project.

Here's how we think about it — and the principles that guide the decision.

The Goal of Week One Is Not to Build Features

This is the counterintuitive part. The goal of week one is not to ship a list of features. It's to create the conditions for fast, confident iteration in every subsequent week.

Those conditions are: a live deployment, a reliable CI/CD pipeline, a codebase that's structured well enough to build on quickly, and at least one thing a real user can touch.

Without those conditions, week two is slower than it should be. Week three slower still. The cost of skipping the foundation shows up as drag on every subsequent week.

The One Real User Test

Once the foundation is in place, we ask: what is the smallest thing we could build that a real user could actually use?

Not a prototype. Not a mockup. Something deployed, at a real URL, that does a real thing. It doesn't have to be polished. It doesn't have to be complete. It has to be real.

The reason for this constraint is simple: the feedback you get from a working feature is qualitatively different from the feedback you get from a description, a wireframe, or a demo. Real users interact differently with real software than they do with anything that looks like software but isn't.

The sooner you get that feedback, the sooner you learn something true.

How We Identify the Right First Feature

We use three filters:

Is it on the critical path? The first feature should be something that other features depend on, not something that could be added last. For most products, this is some version of core user flow — the thing the product exists to enable. Authentication, navigation, and infrastructure plumbing should be invisible by the time users touch the product, but they're often the right things to build first because everything else depends on them.

Is it the highest-uncertainty part of the product? Uncertainty is the enemy of good estimates and fast iteration. If there's a part of the product where we're not sure how it will work, how users will respond, or whether it's technically feasible, that's the part to build first. Learning that something is hard or wrong in week one costs far less than learning it in week four.

Is it small enough to finish? A week one deliverable that isn't finished by the end of week one is a problem. Scope week one to something that can be completed and deployed in five days. If that means cutting scope, cut it. The discipline of finishing something is more valuable than the ambition of starting something bigger.

The Feature That's Usually Right

For most web products, the right week one deliverable is a working version of the core user action — the thing the product is actually for, stripped down to its simplest possible form.

A booking product: a user can submit a booking and an operator can see it.

An internal tool: a user can enter data and see it reflected in a report.

A marketplace: a buyer can browse listings and a seller can post one.

Not the full feature. Not with all the edge cases handled. The core action, working, deployed, usable by a real person.

Everything else is detail. Start with the thing that makes the product real.

Why the Decision Matters More Than the Speed

A lot of teams optimize week one for speed — trying to ship as many features as possible to show progress. This is usually the wrong optimization.

What matters more than speed is building the right thing. A week one that ends with the right feature deployed and learned from is more valuable than a week one that ends with three features deployed that nobody needed.

For the mechanics of how we actually run that first week — day by day — see What Actually Happens in the First Week of a Software Project.

The tempo you want is sustainable. The first thing you want to build is true.