I Have a Startup Idea - What Should I Do Before Building It?

Having a startup idea is easy.

Knowing what to do next is much harder.

You might have an idea for an app, a website, an AI product, a service, or a marketplace.

Something that solves a problem at your college or workplace.

You might even feel strongly that: “Someone should build this.”

But there is a big difference between having an idea and having a startup opportunity.

The mistake many first-time founders make is starting with:

Idea → Build product → Launch → Find customers

A better starting point is:

Problem → People → Evidence → Small solution → Real users → Feedback → Improve

That difference can save months of unnecessary work.

And importantly, you don't need to be a business graduate, experienced entrepreneur or professional developer to start learning how this works.

A school student can begin exploring problems. A college student can test an idea with classmates. A graduate can turn a project into something people use. A professional can discover a business opportunity from a problem they experience at work.

Your Startup Idea Is a Hypothesis, Not a Business

This is one of the most important things a new founder can understand.

When you say: “I have an idea for an app that helps students find internships,” you are making several assumptions:

• students have this problem
• the problem is important
• they currently struggle to solve it
• existing solutions aren't good enough
• students would use your solution
• they would continue using it
• they might eventually pay for it—or someone else might
• you can actually build and deliver the solution

You don't know these things yet. Your idea is therefore better treated as a hypothesis that needs evidence.

YC's Startup School describes an early startup idea in essentially these terms: a hypothesis involving the problem, solution and other assumptions that need to be tested.

That changes the founder's job. Your first job isn't to build the product. It is: “Find out whether the problem and opportunity are real.”

Start With the Problem, Not the Product

Imagine someone says: “I want to build an AI app that helps college students prepare for interviews.”

That's a product idea. But what is the problem? Maybe students:

• don't know what companies ask
• don't know how to practice
• don't receive useful feedback
• don't understand what employers expect
• don't know which skills they are missing

Those are different problems, and each could require a different solution. If you immediately build the AI application, you have already decided the solution before understanding the problem.

Instead ask: Who has the problem? What exactly happens to them? How do they solve it today? How often does it happen? What does the problem cost them? What have they already tried? Why isn't the current solution good enough?

Don't Ask People, “Would You Use My Idea?”

This is one of the easiest ways to get misleading feedback.

Imagine you ask a friend: “I'm building an app that helps students prepare for interviews. Would you use it?” They might say: “Yeah, that's a great idea!”

You feel validated, but nothing has actually been validated. Because people are generally polite, and imagining that you might use something is very different from actually changing your behaviour to use it.

YC recommends focusing early conversations on understanding the user's actual problem rather than simply pitching the idea, and notes that useful user research can start with just one or two conversations rather than immediately talking to thousands of people.

A better question is: “Tell me about the last time you prepared for an interview. What did you do?” Now you're asking about reality.

Ask About What Already Happened

Good customer discovery is often less about asking “What would you do?” and more about asking “What did you actually do?”

For example:

• Instead of: “Would you pay “500 for this?” ask: “How are you solving this problem today?”
• Instead of: “Would you use an AI tool?” ask: “What tools do you currently use?”
• Instead of: “Do you think this is a big problem?” ask: “When did this last happen to you?”
• Instead of: “Would you recommend this?” ask: “What did you do the last time you faced this?”

Real behaviour is much more informative than hypothetical enthusiasm.

You Don't Need 1,000 People to Start

A common beginner mistake is thinking you need to survey thousands of people before you know anything. Not necessarily. You need useful conversations with the right people.

Your first five conversations can reveal things you didn't know. Your next ten can challenge your assumptions. Your next twenty can reveal patterns. YC's guidance on early user research emphasizes starting small and learning from real conversations before trying to scale the research effort.

The goal isn't to collect impressive numbers. The goal is: Find evidence that changes what you believe.

What Should You Look For During Conversations?

Don't just count how many people say: “That's a good idea.” Look for evidence such as:

• Frequency: Does this problem happen often?
• Intensity: How painful is it?
• Current solution: What do people do today?
• Cost: Does it cost them time, money or opportunity?
• Urgency: Do they want it solved now?
• Existing spending: Are they already paying for something?
• Workarounds: Are they doing something inconvenient to solve it?

These clues are much stronger than compliments.

Before Building, Test the Smallest Thing

A strong problem often has a history. Suppose you ask someone: “Would you use a tool that automatically organizes your job applications?” They say: “Absolutely.” Not very useful.

But suppose they say: “I've been maintaining an Excel sheet for six months, I manually update every application, and I keep losing track of interview stages.” Now you have something interesting. They already have a workaround. That means the problem is real enough for them to spend effort solving it.

Your job becomes understanding why their current solution is inadequate. Once you understand it, don't immediately build the complete product. Ask: What is the smallest experiment that can tell me whether my assumption is correct?

This might be: a landing page, manual service, prototype, form, simple website, spreadsheet, WhatsApp workflow, clickable design, or a small software tool. Sometimes you don't need software at all. You can manually deliver the service first. Your goal is to prove: Someone actually wants the outcome.

What Is an MVP Really For?

MVP stands for Minimum Viable Product. But it is often misunderstood as “the smallest product I can build.” A better way to think about it is: The smallest useful version that lets you test whether people actually want the solution.

YC describes the MVP as the first product used to test demand and validate a business opportunity. That's why an MVP shouldn't contain every feature you can imagine. You need enough to answer: “Does this actually provide value?”

Do not build for six months before finding users. If you spend six months designing and developing before anyone uses it, you may learn that nobody wants it—but at a very high cost. A better approach is to get something small in front of people much earlier. YC's startup guidance repeatedly emphasizes launching early, getting initial users, talking to them and iterating.

The first version can be ugly, incomplete, and require manual work. That's okay.

Your First Users Are Not Just Customers

They are also your teachers. Suppose ten people use your first version. They may show you what they actually want, what they ignore, where they get confused, what feature they repeatedly request, where the product fails, what they would pay for, and who else has the problem.

That's why Users → Feedback → Iteration is more valuable at the beginning than Features → Features → Features.

Your first version will probably be wrong. That's normal. Your original idea, target customer, pricing, product, or entire business model might change. That doesn't mean you failed. It means you learned something.

YC's startup guidance explicitly frames the early startup process around building, launching, learning from users and changing direction when the evidence demands it. A startup is a process of discovering what works.

Where Should Your First Startup Idea Come From?

You don't need to invent a completely new problem. Some of the strongest starting points are problems you already experience.

College students have a unique advantage: classmates, alumni, clubs, professors, and community groups are right there. You don't need to reach 100,000 people. Start with five people who genuinely experience the problem.

Graduates can turn projects into opportunities. A project can become portfolio → users → product → business or portfolio → users → evidence → job. The same project can create different paths depending on what you discover.

Don't Start With Investors

You don't need funding to prove that an idea is useful. You don't need an investor to tell you whether users want it. You don't need a pitch deck before talking to customers. And you don't need a company registration before testing a problem.

Your first validation should come from reality: people using it, returning, referring others, and paying. Those signals are much more informative than applause for a pitch. YC's startup guidance similarly warns against treating investor interest as the primary validation mechanism at the idea stage.

Don't confuse attention with validation. 1,000 people visiting is not validation if only five sign up. Signups are not active users. Active users are not retention. Retention is not revenue. Startup building is a sequence of increasingly strong evidence.

At the beginning, measure signals that actually matter: Who is using it? Is the problem real? Does the product provide value? Do they come back? Will they pay? Will they tell others?

A Startup Is a Learning System

You start with assumptions. Then reality tests them. You learn. You change something. Reality tests it again:

Assumption → Experiment → Evidence → Decision → Next experiment

The faster you can run useful experiments without wasting resources, the faster you learn. This is why startups move quickly.

Why is a real startup-building environment different from an entrepreneurship course? A traditional course teaches business concepts, case studies, terminology, and frameworks. Those are useful, but a real building environment adds actual problems, projects, users, feedback, and uncertainty.

Instead of discussing validation, you try to validate. Instead of studying an MVP, you build one. Instead of discussing customer acquisition, you try to find your first customer. That is a fundamentally different type of learning.

OECD research on entrepreneurship education describes action-based approaches including project work, customer development, pitching, and venture creation, emphasizing acting on knowledge.

So What Should You Do If You Have an Idea Today?

Don't start coding tonight. Don't create a logo. Don't register a company. Don't make a pitch deck. Don't look for investors. Do this instead:

1. Write the problem clearly: Who has it?
2. Describe the current situation: How are they solving it today?
3. Talk to people: Speak to people who actually experience it.
4. Look for evidence: Find out whether the problem is frequent, painful, and meaningful.
5. Define the smallest useful solution: What is the simplest thing you can put in front of someone?
6. Get your first users: Don't wait for perfection.
7. Watch what they do: Not what they say.
8. Improve: Build based on evidence.
9. Decide: Continue, change direction, or stop.

Stopping an idea after learning that the problem isn't valuable isn't wasted work. It is successful validation. The best startup environment is one where you can be wrong and discover it quickly.

Your first goal is not 1,000 users. Your first goal might be one real user. Then five. Then ten. At each stage, ask why they use it, why others don't, and what keeps them coming back.

A startup doesn't become real because you call it a startup. It becomes real when someone outside your head uses it, returns, pays, and recommends it. The journey starts before the product, and the path doesn't always move forward. The purpose is to keep learning from reality.

You don't need permission to start exploring. A school student can identify a problem. A college student can build a project. A graduate can test a product. A professional can run an experiment. Start with a problem. Talk to people. Build something small. Get it into the hands of real users. Learn. Improve.

The most valuable thing you can build may not be the startup; it might be your ability to build. You learn opportunity discovery, communication, decision-making, engineering, sales, and resilience. Those capabilities stay with you. That is why startup building is a powerful form of education.