Most first-time founders spend month one building. It is the single most expensive mistake we see, and it is expensive precisely because it feels like progress.
Building is legible. You open the editor, you ship a feature, and you can point at the thing you made. Validation is illegible. You have a dozen conversations and end the week with a slightly better-calibrated sense of whether anyone wants what you are about to spend a year on. One of those activities produces an artifact. The other produces judgment. Founders who confuse the two tend to discover, around month five, that they built a beautifully engineered answer to a question nobody asked.
What follows is a structure for the first 180 days. A default, not a law: the shape we would reach for if we were starting again, drawn from conversations with founders who are now somewhere between month seven and year three. Adjust it to your situation. But adjust it deliberately, not by drifting into the editor because the editor is the comfortable place to be.
Month one: validate
The goal of month one is to earn the right to build. Nothing else.
That means conversations, and a specific kind. Rob Fitzpatrick’s The Mom Test names the core discipline: ask about the person’s actual past, not their imagined future. “Would you use this” gets answered kindly and uselessly every time. The questions that produce signal are different. “What did you do the last time this came up?” “What did that cost you, in time or money?” “What do you currently use to make it go away?” People are unreliable narrators of their future and fairly reliable narrators of the last six months. The Jobs To Be Done framing is useful here, too: you are not asking about your product, you are asking about the job the person is trying to get done and what hired-and-fired a series of inadequate solutions.
Underneath all the answers, you are listening for one thing. Is this problem a headache or an emergency. Headaches get sympathy. Emergencies get budget. A surprising number of real, genuine, well-described problems are headaches, and headache businesses are very hard to start because nobody is motivated enough to switch away from whatever they tolerate today.
How many conversations is enough? Not a fixed number, but enough that you start hearing the same sentences come back unprompted. When three different people describe the same workaround in nearly the same words, you have found something. When every conversation surfaces a new and unrelated complaint, you have found a category, not a problem.
By the end of month one you should be able to write one honest paragraph: who has this problem, how often, what it costs them now, and what they currently do instead. If you cannot write that paragraph without inventing parts of it, you do not yet have permission to build. Stay in month one. It is cheaper than month five.
Month two: define the minimum
Month two is where most so-called MVPs go wrong, because the word minimum gets read as small when it should be read as honest.
The minimum is not the smallest thing you can build. It is the smallest thing that, if it works, actually tells you something true. A small build that cannot fail informatively is not a minimum viable product. It is a demo, and a demo mostly tests whether you can build, a question you probably already know the answer to.
Spend month two on two things. First, write down the single belief your product depends on most: the one belief that, if false, sinks everything else. Second, design the smallest test that puts real pressure on that belief. Sometimes the test is software. Often, in month two, it is not. A Carrd or Framer landing page with a Stripe Payment Link and a real consequence for clicking it tells you more about demand than six weeks of code. A Typeform collecting structured intake, routed into a Notion doc that you process by hand, lets you run a service before you automate it. These are not hacks. They are how you find out whether anyone wants the thing before committing to building the thing.
The deliverable of month two is a plan you could hand to someone else, plus one written sentence describing exactly what outcome would change your mind.
The minimum viable product is not the smallest thing you can build. It is the smallest thing that, if it works, tells you something true.
Month three: ship something real
Month three is the build. One month. The constraint is the point.
A one-month build forces the scope conversations you would otherwise avoid. It makes you cut the settings page, the onboarding flow, the second use case, the admin panel: all the things that feel responsible and are actually delay wearing a suit. If your minimum genuinely cannot be built in a month, the minimum is still too big, or you are building infrastructure you do not yet need. Both are common. Both are far cheaper to fix in month three than in month five.
Ship it to real people who can say no. Not friends, not the supportive group chat. People who have the problem, have a budget, and have no particular reason to be kind to you. A B2B SaaS founder in their third month of validation once described the first time a stranger, with no connection to them, signed up through an unannounced link and started using the product without asking a single clarifying question. That moment told them more than the preceding eight weeks of feedback calls.
Month four: watch
Month four is the hardest to hold, because it asks you to stop.
Resist the urge to immediately build the next thing. Watch instead. Not what people say in a call, but what they do when no one is on the call. Where do they stop. What do they do twice because the first way did not work. What do they never touch.
PostHog or Mixpanel will show you event-level product behavior: which flows complete, where drop-off happens, which features never get touched after the first session. Pair that with session replay from Hotjar or Microsoft Clarity (Clarity is free, which is the main reason it shows up at this stage). GA4 handles traffic basics if you need to understand how people arrive. Together these tools make the gap between what users say and what they do legible and specific.
The instinct in month four is to read every piece of feedback as a feature request. Most feedback is a symptom. Someone asking for a button is often describing a workflow you got slightly wrong three screens earlier. Your job is to be a diagnostician, not an order-taker. Sit with the discomfort of not shipping. The discomfort is the work.
Month five: iterate
Now you build again. But you build against evidence, which is a completely different activity from building against hope.
Month five is for the small number of changes that month four made undeniable. Not the long list. If month four was done honestly, you will already know which changes those are, because they are the ones you kept noticing. Make them. Ship them. Watch again, briefly.
Month five is also when you start being honest about the shape of demand. Are the same people coming back? Is anyone telling someone else without being asked? Is anyone paying, or seriously close to paying? You are not looking for a hockey stick. You are looking for a pulse: small, real, and repeatable. A pulse is enough to justify month seven. A hockey stick at month five is usually a measurement error.
Month six: decide
Month six is a decision, and it deserves to be treated as one. Founders who never schedule the decision tend to make it anyway, much later, by exhaustion, which is the worst possible way to make it.
There are three honest outcomes. All three are respectable.
Commit. The evidence is there. Not loud, but real and repeatable. The next six months are about depth: making it better for the people who already want it. This is the outcome everyone hopes for, and it is rarer than month-one optimism suggests.
Adjust. The problem is real, but you are solving it for the wrong people, or solving the wrong slice of it. You have learned where the heat is. The next six months are a second, much better-informed attempt. This is the most common honest outcome, and founders treat it as failure far too often. It is not failure. It is what months one through five were for.
Stop. The evidence is not there, and continuing would be a decision to ignore your own data. Stopping at month six is six months spent instead of three years, and the three years you did not spend are the entire return on running the process at all.
The point of the structure
None of this is about rigidity. Plenty of good companies were built by founders who ignored every word of it. The structure matters because it forces the decision that founders most want to defer: should this exist at all. Building lets you postpone that question indefinitely, and the postponement feels like momentum right up until the month the runway math stops working.
Six months is enough time to find out whether you are onto something, and short enough that being wrong is survivable. The Stripe Payment Link on the Carrd page either converts or it does not, and that answer arrives in a week rather than a quarter.
