Month 1: From Idea to Validated Problem

The first month is not about building. It's about finding out whether the problem you want to solve is real, widespread, and worth solving.

Spend the first two weeks doing problem interviews — 20 to 30 conversations with people who you think have the problem. Don't pitch your solution. Ask about their current workflow, their workarounds, and what the problem costs them in time, money, or stress. If multiple conversations independently surface the same friction, you have a real problem.

The second two weeks are about defining the solution hypothesis. Based on what you heard, what's the simplest possible way to solve the core problem? Write a one-paragraph product description. Draw three screens on paper. Get the core idea clear enough that someone can respond to it.

By the end of month one you should know: is there a real problem? Does my solution address it? Who specifically are my target users?

Month 2: Define and Design

Month two is about design — not visual design, but structural design: what is the product, exactly? What does a user do in their first session? What's the core action loop?

Build low-fidelity wireframes (or prototype in Figma) and put them in front of 10 people from your target group. Don't explain the product — watch them try to use it. Where do they get confused? What do they expect that isn't there? This prototype feedback is 10× cheaper to act on than production feedback.

At the end of month two: you have a tested wireframe, a clear definition of the MVP scope, and at least 5 people who've told you they'd use this if it existed.

Month 3–4: Build the MVP

This is when the development sprint starts. Months three and four are heads-down build time. The critical principle: protect the scope. Every week, someone will suggest adding a feature. Every week, you need to ask "does this help the core user journey, or is it a distraction?"

Key practices during the build:

• Weekly demos to one or two target users — not to show off, but to catch wrong assumptions early while they're cheap to fix
• Feature flags for everything — ship incrementally, don't big-bang launch
• Staging environment from week one — "it works on my machine" is not a sufficient test

By the end of month four, you should have a product that's rough but functional — something a real user can complete the core task with.

Month 5: First Users, Real Feedback

Month five is your private beta — getting the product into the hands of real users who aren't your friends. Reach out directly to people from your month-one interviews. Offer white-glove onboarding. The goal isn't scale; it's learning.

Expect things to break. Expect users to be confused by things you thought were obvious. This is normal and valuable. Run weekly calls with your first 10 users. Ask what they did, what they tried to do, and where they got stuck.

By end of month five: you've onboarded 10–20 real users, have a list of the top 10 things to fix, and have at least 3 users who've told you the product already saves them time.

Month 6: Iterate and Open the Door

Month six is iteration and public launch preparation. Fix the most critical issues from the private beta. Improve onboarding — the path from sign-up to first value should be under five minutes. Write simple documentation for the questions users keep asking.

Then launch — not with a Super Bowl ad, but with presence in the communities where your users already spend time. A post on Reddit, a relevant Slack group, Product Hunt, a LinkedIn post from your personal account. The goal is 50–100 sign-ups from people who don't know you.

Watch what happens in the first week. Do users come back day two? Day seven? Where do they drop off? The answers to these questions are your next three months of work.

What Kills Startups at This Stage

• Spending months one and two building instead of talking to users
• Pivoting before the first version ships — getting cold feet about the idea before you have real evidence
• Waiting for "done" to launch — if you're not embarrassed by v1, you launched too late
• Hiring before you have something to build — team before product is expensive confusion

Six months is a long time. It's also not very long at all. The startups that cover the most ground in this period are the ones that treat every week as a learning unit — what did we learn, what do we know now that we didn't last week, and what does that mean for next week's priorities?