What You Actually Get Out of Week 1

Most software projects fail in week 1.

Not visibly — nobody misses a deadline in week 1. The failure is quieter: a vague scope that never got challenged, a data model that felt obvious but wasn't, a "hard part" that everyone sensed but no one named. The project starts anyway, and the bill for that first week comes due somewhere around week 8.

Discovery week is how we avoid that.

We call it Week 1 in our 12-week breakdown, but it deserves more than a paragraph. It's the week where a senior engineer asks uncomfortable questions, makes fast decisions, and hands you three documents that determine whether the next 11 weeks go well or go sideways.

Here's exactly what happens.

The four conversations

We don't start week 1 with a Figma file or a Jira board. We start with four conversations — sometimes in separate sessions, sometimes rolled into one long working session depending on the project.

1. The job conversation

Not: "what features do you want?" Instead: "what is the user actually trying to do?"

Features are answers to questions. If you don't know the questions, you build the wrong answers. This conversation is about the underlying job — the thing a user is trying to accomplish that your product makes easier, faster, or possible at all.

This conversation is harder than it sounds. Most founders have been living in feature-thinking for months. We push until we can articulate the job in one sentence. If we can't, we're not ready to build.

2. The scope conversation

What is the smallest version of this product that is still genuinely useful?

Not a toy. Not a proof of concept. A real thing that a real user would pay for or rely on — just stripped to the bone. Everything else is phase 2.

We go through the feature list and sort everything into three buckets:

Must-have: The product doesn't work without this.
Nice-to-have: It's better with it, but launch can happen without it.
Phase 2: Real and valuable, but not now.

The nice-to-haves and phase-2 items don't disappear — we keep a running list. But they don't touch the build plan until we ship.

3. The hard-parts conversation

Every project has something in it that is genuinely difficult. We've seen: AI integrations with unpredictable latency, real-time collaborative editing, pricing logic with enough edge cases to fill a spreadsheet, and third-party APIs that were designed in 2009 and haven't been touched since.

Whatever it is, we want to know about it in week 1, not week 7.

This conversation is about identifying the one or two things that could blow up the timeline, and making a plan for each of them. Sometimes the plan is "build a spike in week 2 to see if it's actually hard." Sometimes it's "scope this differently so the hard part is optional." Either way: better now.

4. The data conversation

Get the nouns right and the rest follows.

The data model is the skeleton of the product. If it's wrong, everything built on top of it is wrong too — and fixing it later means ripping out load-bearing walls. We spend real time on this in week 1: What are the core entities? How do they relate? What are the edge cases in the relationships?

A good data model isn't clever. It's boring and obvious — which is how you know it's right.

The three artifacts

By the end of week 1, we produce three documents. They're short by design.

1. The architecture doc (one page)

The architecture doc answers: what are we building, how does it work, and what does it run on?

It covers:

The tech stack (and why, where the choice wasn't obvious)
The deployment target
How authentication works
The key user flows at a high level
Any significant third-party integrations

One page. If it's longer, we don't understand it well enough yet. This isn't laziness — it's a forcing function. Complexity on page two usually means confusion that will show up as a rewrite in week 9.

2. The database schema sketch

Not a final schema. A sketch — the core entities and relationships, drawn out far enough that we can build on it without second-guessing ourselves in week 3.

The goal isn't perfection. It's alignment. A shared schema means the engineer and the client aren't making contradictory assumptions about how the data fits together.

We revisit this in week 7 when we do our scope check. Most of the time it holds up. Occasionally we catch something that needs adjusting before it becomes permanent.

3. The build plan

A prioritized list of work, roughly organized by week. Not a Gantt chart — those are fiction. A list of what comes before what, and why.

The build plan answers: given this scope and this team, what's the realistic order of operations? It bakes in the dependencies (you can't build search before you have data, can't build permissions before you have users) and flags the things that need to happen before other things can start.

It also becomes the primary communication tool for the rest of the project. Every Friday, we update it. When scope changes, it changes. It's the artifact that keeps the project honest.

The known unknowns list

This one doesn't get talked about enough.

At the end of week 1, we write down everything we don't know yet that could matter. Not bugs — we haven't written code. Known unknowns: open questions, things we assumed but haven't validated, integrations we need to test before we bet the timeline on them.

Examples from real projects:

"We don't know if this payment provider's API supports the refund flow we need — need to check before week 8."
"The client hasn't confirmed whether users will be on mobile or desktop — affects the UI approach significantly."
"The AI response time is unknown — if it's > 3 seconds, we need a different UX."

The list doesn't have to be long. It just has to be honest. A known unknown on a list is a managed risk. A known unknown that nobody wrote down is a surprise.

What if week 1 goes badly?

Sometimes it does.

The most common version: the scope conversation reveals that the project as described is either much larger than the timeline allows, or rests on an assumption that doesn't hold up under questioning. We've had discovery weeks end with us telling a founder that their "MVP" is actually a 6-month build, and that what they can ship in 12 weeks is a focused version of one core workflow.

That's not a failure — that's the discovery week working correctly. Finding it in week 1 costs a week. Finding it in week 10 costs the project.

The second version: the data conversation reveals a fundamental ambiguity in what the product is. Who is the primary user? What's the actual value exchange? If we can't answer those by the end of week 1, we're not ready to build. We've paused projects at this point rather than start building on a shaky foundation.

Neither of these is fun. Both of them are better than the alternative.

Discovery as a filter

We'll be honest about one more thing: Week 1 is also how we decide whether we're the right fit for a project — and whether you're the right fit for us.

A productive discovery week requires a client who can answer hard questions quickly, who trusts our judgment on technical tradeoffs, and who is genuinely willing to cut scope when the scope is too big. If those conditions aren't there in week 1, they won't magically appear in week 8.

Most of the time, week 1 goes well. We end it with a clear scope, a solid schema, a build plan we believe in, and a working relationship that's ready for the next 11 weeks.

When it doesn't go well, it's almost always better to know in week 1.

What this means for you

If you're considering hiring a development team — us or anyone else — ask them what they do in week 1. Ask what you'll have at the end of it.

The answer should be specific. If it's "we'll get aligned on requirements," that's not an answer — that's a placeholder. If it's three named documents and a list of known unknowns, that's a team that has done this before.

Our discovery week is also how we start every engagement. If you want to see how it goes in practice, the first 30 minutes are on us. We'll tell you honestly whether your project is ready to build — and if it's not, we'll tell you what it would take to get there.

Signal Shift Labs is a two-person studio building software for founders, small businesses, and teams that need to move fast and build right. Read more about our process or see what we've built.