Should I Build This Startup Idea? A Quick Notebook Pre-Test

Most founders decide whether to build an idea the same way they decide what to have for dinner: by feel. Then they lose a weekend to a prototype nobody had asked for. A short pre-test, written in longhand, beats every model that tells you the idea sounds promising.

The pre-test is a handful of questions. A notebook, a pen, a small window of quiet. No signup, no model, no spreadsheet. The answers decide whether the next Saturday belongs to this idea or to a better one. From raw to well done — but the raw work has to happen first, in your own handwriting, before any tool gets near it.

What this test decides

The test decides one thing: whether your idea earns the next Saturday or loses it. Answer five questions in a notebook, in longhand, before you open a code editor or spend a dollar. No tool required. The answers tell you whether the idea has enough signal to justify a prototype, or whether the weekend is better spent elsewhere.

The goal is not a score. It is a go/no-go decision made with evidence instead of instinct.

A score invites rationalization. A binary decision, written down, with your name on the page, is harder to argue with. You either wrote a specific person, or you didn't. You either wrote a dollar amount, or you wrote "nothing." A high score sounds respectable. A blank space does not.

The test costs nothing. A failed test costs a Saturday. A built-when-you-should-not cost far more than that.

Who has this problem right now

Write the name or description of a specific person who has this problem today. Not "small businesses" — a founder who exports invoices to CSV every Monday. Not "developers" — the solo builder who loses three hours a week to manually updating a pricing table. If you cannot write a specific person with a specific frustration, the problem is in your head, not the market.

A vague problem produces a vague solution. The test fails here if you cannot name a person.

The phrase "small businesses" describes nobody. "Founders" describes millions. The notebook forces a name — even a fake one, even a composite — because the act of writing a person changes the question. "Does this person exist?" is answerable. "Do small businesses need this?" is not.

Picture them at their desk. What tab is open. What did they try before. What they typed into the search bar that returned a page of results, all of which they ignored. The notebook is where this person comes into focus. Without it, the rest of the test is fiction.

How they are solving it today

Write what they do instead of your idea. A spreadsheet, a combination of two tools, a manual process with a workaround, or nothing at all. Include the cost: time, money, or frustration. This is your competition — not another startup, but the current behavior. If they are doing nothing, write why nothing is fine for them right now.

If the workaround is good enough, your idea needs a better reason to exist than convenience.

The spreadsheet is usually the biggest competitor in software. Then comes a duct-taped combination of apps. Then comes doing it manually on Friday afternoon. None of them raise money. All of them are still there when your MVP launches.

Write the workaround by name. "They use Notion plus a Google Sheet plus a monthly Slack reminder" is a sentence that tells you exactly what to replace. "They use various tools" tells you nothing. If the workaround has several steps, your product has to beat those steps, not nothing. The cost is what proves the pain: hours, dollars, lost deals, missed invoices. A workaround with a number is a problem worth solving. A workaround without a number is a hobby.

What they would pay to fix it

Write the dollar amount they would spend today to stop this problem. Not a price you think is reasonable — the amount they actually budget when this specific pain hits. If they would spend nothing, write the reason. If they paid a previous solution, write what they paid and why they stopped.

The answer is a number or "nothing." Write the number or write nothing.

A price is a confession. Founders imagine a tidy monthly subscription because that is what they would pay. Customers imagine the same number as a few coffees they could have bought. The two rarely agree.

If the answer is nothing, the test has already told you the answer. An unfixable free tier exists in the workarounds above. If they are willing to pay, write the number you have actually seen someone pay — for a previous tool, for a consultant, for a freelancer to do it once. A price with provenance is harder to argue with than a price you made up on the way to this paragraph. If they paid a previous solution and stopped, that is a gift. The reason they stopped is the most valuable sentence in the notebook.

Where to find these people

Write three places where this specific person congregates. A subreddit, a Slack community, a conference, a LinkedIn group, a GitHub repo, a specific hashtag. If you cannot name three places, you cannot reach them. If you cannot reach them, the idea cannot become a business no matter how good it is. The reachability of your audience is a product decision.

Distribution is not a later problem. It is part of the pre-test.

"Build it and they will come" is a movie. Distribution decides which products survive long enough to matter and which die in a Reddit thread that nobody bothered to write. The notebook is where you write the places you will actually show up — not the places you wish existed.

Examples are useful here. A founder targeting indie SaaS builders can write Indie Hackers, a specific Slack workspace, and the comment threads of certain product launches on X. A founder targeting freelance designers can write design communities where the same complaints appear every month. The places have to be specific. "Online" is not a place. Neither is "social media." If all the places are in your head, the audience is in your head too.

The simplest version that proves the job

Write the cheapest possible version of your idea that still proves the core value. A Google Form, a Loom walkthrough, a manual DM response, a Calendly booking. The version you could build in a day or less if you had to. If you cannot write a version simpler than your current idea, your idea is not minimal enough.

The test does not care about your build. It cares about whether the job is worth doing.

A Google Form is not a product. It is a test. A Loom is not a product. It is a test. The point is to do the job by hand and see if anyone will pay for it to stop being done by hand. If the manual version attracts no one, the coded version will not either.

The shape of the manual version tells you what the real product has to do. If a handful of people fill out the form and someone asks whether the result can happen automatically, you have evidence. If nobody fills out the form, you have a different kind of evidence — and a Saturday you did not spend writing code nobody wants.

The test that decides the weekend

The idea passes if you can answer all five questions with specificity. It fails if any answer is vague — "many people," "some workaround," "a fair price." Vague answers are not early-stage uncertainty. They are a signal that the problem is unconfirmed. Keep the notebook. Answer the vagueness with evidence before you build. The Saturday belongs to the clearer idea.

Passing the test is not a guarantee. Failing it is a guarantee of wasted time.

Vague answers feel like progress. They are not. "Some people have this problem" sounds like research. It is a confession that you have not done the research. The notebook turns the vague sentence into a specific one or admits there is no specific sentence to write. Both outcomes are useful. The only outcome that costs a weekend is building anyway.

This is the gate. The questions in the notebook are the gate. Each answer is a lock. Either the lock opens, with a name and a number, or it does not. A failed test is not a bad day. It is the day you saved future Saturdays.

Three places to find real evidence

If the notebook test passes, find evidence in three places. Read what people write in communities where your specific person congregates — Reddit threads, Hacker News replies, app store reviews. Check whether public funding programs exist for this type of work — grants sometimes reveal where governments believe the gaps are. Look for direct quotes in the words people actually use to describe the problem. Those phrases are the copy that proves it exists.

Evidence is not the same as validation. Evidence is a verifiable claim you can trace to a source.

A research tool that only returns good news has told you nothing. The same is true of an evidence hunt that only finds what you went looking for. The places below are not equally useful, and none of them replaces the specific person in your notebook. They do, however, put walls around the claim so it stops being your opinion and starts being something a stranger can read and recognize.

The places are not a substitute for the specific person in your notebook. Communities tell you what people say when nobody is selling to them. Reviews tell you what people say when something exists and they want it to be different. Funding portals tell you what institutions believe is worth investing in. The phrases people use in a frustrated Reddit comment are the phrases that go in your landing page. The complaint in a scathing review of a competitor is the headline that earns the click. The funding call that lists your category among its priorities is a signal that other people are putting money behind the same gap you noticed.

Every quote that lands on the page should be one you can open, copied from a source, never written from memory. That is how raw becomes well done — and how a notebook full of soft beliefs becomes a pre-test with a clear answer.