A Practical, Phase-by-Phase Guide to Building a Startup
Most people don't struggle to find startup advice. They struggle to turn that advice into action.
You can spend hours watching successful founders discuss ideas, product development, customer acquisition, pricing, and fundraising. You may finish the entire playlist feeling smarter, yet still have no product, no customers, and no evidence that your idea will work.
That is the trap this guide is designed to prevent.
Y Combinator's Startup School playlist covers many of the core decisions involved in starting a company. Instead of treating it as a course you must finish before starting, use it as a practical playbook that helps you make those decisions while building.
The central principle is simple:
Learn what you need, execute immediately, measure what happens, and return to learning when you encounter a real problem.
Here is how to turn the lessons into an execution-focused roadmap.
Phase 1: Decide What You Are Building and Why
Objective: Establish whether starting a company makes sense for you.
A startup is not simply a business idea or an opportunity to build an interesting product. It involves uncertainty, persistent problem-solving, and the willingness to work through problems without guaranteed results.
Before committing to an idea, ask yourself:
- Am I solving a problem that matters to someone?
- Am I willing to spend significant time understanding this problem?
- Do I have a reason to pursue it that goes beyond excitement about the idea?
- Am I prepared to learn from rejection and change my approach?
You do not need the perfect background, a prestigious degree, or a fully developed business plan to begin. What matters at this stage is whether you can commit to learning and doing the work.
Execute this phase
Write a one-page founder brief containing:
- The problem you want to solve.
- The people who experience it.
- Why the problem matters to you.
- The time and resources you can commit over the next 30 days.
- What evidence would convince you to continue or stop.
Deliverable: A clear commitment and a problem area worth investigating.
Exit criterion: You can explain what you want to explore and why without relying on vague claims about changing the world.
Do not spend weeks debating whether you are ready. Begin with a small, reversible commitment and learn from the process.
Phase 2: Find a Problem Worth Solving
Objective: Choose a promising problem instead of falling in love with an idea.
Many founders start with a solution. They imagine an app, a website, or an AI-powered product and immediately begin building it.
That reverses the process.
Start by identifying people who experience a recurring problem. Look for situations where existing solutions are expensive, inconvenient, slow, unreliable, or simply inadequate.
Good places to look include your own work, industries you understand, repetitive tasks, and communities where people regularly complain about the same issue.
Execute this phase
Create a list of 10 problems you have observed.
For each problem, record:
- Who experiences it?
- How frequently does it occur?
- What do people currently do about it?
- What does the problem cost them in time, money, or frustration?
- Can you reach these people directly?
Select one problem to investigate first. This is a working hypothesis, not a permanent decision.
Deliverable: One specific problem and a clearly defined group of potential customers.
Exit criterion: You can describe the target customer and their problem in two sentences.
For example:
Instead of saying, "I want to build an AI productivity app," say, "Independent consultants spend hours converting meeting notes into client updates, and I want to find out whether that task is painful enough for them to pay for a better solution."
The second statement gives you something to investigate.
Phase 3: Find the Right Co-Founder—or Start Alone
Objective: Build the right team structure for the problem you want to solve.
A co-founder can bring complementary skills, shared responsibility, and additional perspective. But choosing someone merely because they are available, enthusiastic, or a friend can create more problems than it solves.
The important question is not whether two people get along socially. It is whether they can work together under pressure, make decisions, handle disagreements, and remain committed when progress is slow.
Execute this phase
If you are considering a co-founder:
- Discuss your long-term goals and personal constraints.
- Compare expectations about workload, ownership, money, and decision-making.
- Work together on a small project before making a long-term commitment.
- Observe how each person handles missed deadlines and disagreements.
If you do not have a suitable co-founder, continue validating the problem and developing your skills. Do not force a partnership simply to feel more legitimate.
Deliverable: A tested working relationship, or a clear plan for operating independently while exploring team options.
Exit criterion: Responsibilities, commitment, and expectations are explicit.
Remember: a co-founder is a long-term working relationship, not a checkbox on a startup checklist.
Phase 4: Talk to Potential Customers
Objective: Replace assumptions with real evidence.
This is one of the highest-leverage activities for an early-stage founder.
Your friends may like your idea. Online communities may praise it. People may tell you they would use it someday.
None of that proves they have a meaningful problem or will pay for a solution.
Customer conversations should help you understand what people actually experience, not persuade them that your idea is brilliant.
Execute this phase
Speak to 10–15 people who belong to your target customer group.
Ask questions such as:
- Tell me about the last time you encountered this problem.
- How do you handle it today?
- What have you already tried?
- What is the most frustrating part?
- How much time or money does the current approach cost you?
Avoid leading questions such as, "Would you use my app if I built it?"
People are often generous with hypothetical enthusiasm and much less generous with their time and money.
Record the answers. Look for repeated patterns, existing workarounds, and evidence that the problem is important enough to address.
If possible, offer a manual solution to a few people before building software.
Deliverable: A list of recurring customer problems, existing alternatives, and initial evidence of demand.
Exit criterion: You can identify a specific problem that several target customers have actually experienced, with enough evidence to justify testing a solution.
Ten conversations are a starting point, not a universal statistical threshold. Continue until the findings are sufficiently clear to make a decision.
Phase 5: Build the Smallest Useful Product
Objective: Deliver one meaningful outcome with the least unnecessary complexity.
An MVP, or minimum viable product, is not a broken version of your dream product.
It is the smallest product or service that lets you test an important assumption and deliver value to an initial customer.
Your first version does not need a sophisticated interface, dozens of features, elaborate automation, or a perfect technical architecture.
It needs to solve a real problem well enough to teach you something useful.
Execute this phase
Choose one specific user problem and define:
- The intended user.
- The single core task the product must perform.
- What the user receives at the end.
- How you will know whether the solution works.
Then build only what is necessary to deliver that outcome.
Depending on the problem, your MVP might be a simple website, a spreadsheet, a manual service, a lightweight app, or a basic software workflow.
For example, before building a fully automated AI reporting platform, you could generate reports manually for three customers. This lets you learn what information they value before investing in automation.
Deliverable: A working, testable solution that real users can experience.
Exit criterion: At least one target customer can use the solution and obtain the intended outcome.
Do not confuse a demo with an MVP. A demo shows what might work; a useful MVP tests what actually works for a customer.
Phase 6: Launch Early and Acquire Your First Customers
Objective: Put the product in front of real people and learn through use.
Launching is not a ceremonial event. It is the beginning of a more demanding feedback loop.
You do not need a massive audience, a perfect brand, or a major launch announcement before getting started. Initially, you need direct access to people who have the problem you are solving.
Execute this phase
Start with a manageable group of potential customers.
- Contact people you interviewed during validation.
- Demonstrate the product in a real-world context.
- Help early users complete the process.
- Ask what worked, what failed, and what prevented them from using it again.
- Make improvements based on observed behavior.
In the beginning, manual outreach and personal assistance are often more useful than spending heavily on advertising or attempting to automate every part of customer acquisition.
Measure meaningful actions: conversations that turn into trials, completed purchases, successful outcomes, and repeat usage.
Deliverable: Your first active users and a repeatable process for reaching potential customers.
Exit criterion: You can explain how you obtained your first users, what they used the product for, and why they did or did not return.
A launch is not successful because people viewed your announcement. It is successful when it helps you learn whether the product deserves further investment.
Phase 7: Test Pricing and the Business Model
Objective: Determine whether creating value can become a sustainable business.
A product can attract interest without becoming a viable business.
You need to understand who pays, what they pay for, how often they pay, and whether the economics can work as the company grows.
Pricing should therefore be tested with customers, not decided entirely in a spreadsheet.
Execute this phase
Write down:
- Who is the buyer?
- What outcome are they paying for?
- What alternatives do they currently pay for?
- What price will you test?
- What does it cost to deliver the product or service?
Present a specific offer to potential customers. Observe whether they purchase, hesitate, negotiate, or decline. Follow up to understand the reasons.
Track revenue alongside the costs of delivering your product, acquiring customers, and supporting them.
Do not assume that a large market automatically creates a viable business. You still need a solution customers value and a model that can support the business.
Deliverable: An initial pricing hypothesis and a basic business model.
Exit criterion: You have tested a real offer and gathered evidence about willingness to pay and delivery costs.
You do not need perfectly optimized pricing at this stage. You need enough evidence to make the next decision intelligently.
Phase 8: Build a Sustainable Execution System
Objective: Keep making progress without getting trapped in endless planning or unnecessary engineering.
Technical founders can lose weeks optimizing infrastructure before validating demand. Nontechnical founders can lose weeks searching for developers, tools, and funding instead of testing the problem.
Both approaches can delay the most important work.
Choose technology based on the problem, the users, and the stage of the company. Favor the simplest approach that lets you learn quickly without creating unacceptable reliability, security, or operational risks.
Execute this phase
Every week, define three things:
- One outcome: The most important result you need to achieve.
- One experiment: The action that will test your biggest uncertainty.
- One metric: The evidence that will tell you whether progress is happening.
Keep a record of what you built, whom you contacted, what you learned, and what you will change next.
Avoid adding features simply because competitors have them. Avoid rewriting working software merely because a newer tool looks attractive. Improve the product when the improvement solves a demonstrated problem.
Deliverable: A weekly execution rhythm with visible progress and documented learning.
Exit criterion: Every week produces a useful output, a tested assumption, or a clear decision about what to do next.
The goal is not to remain busy. It is to reduce uncertainty while building something customers value.
Phase 9: Decide Whether Fundraising Makes Sense
Objective: Understand how external capital could help the business progress.
Fundraising is one possible way to finance a startup, not proof that a startup is succeeding.
Before pursuing investors, know what the business does, who it serves, what progress has been made, and what additional capital would allow you to accomplish.
Depending on the business, raising money before launch may be appropriate. For others, customer revenue or a smaller initial operation may be the better starting point.
Execute this phase
Prepare concise answers to these questions:
- What problem does the business solve?
- Who is the customer, and how do you reach them?
- What evidence suggests the solution is valuable?
- What progress have you made?
- What will the money fund?
- What specific milestone should that investment help achieve?
Learn about the fundraising process, investor expectations, dilution, and financing terms before accepting capital.
If you are considering applying to Y Combinator, study its official Startup School resources and current application information.
Deliverable: A clear financing decision and, when appropriate, an evidence-backed fundraising plan.
Exit criterion: You can explain why external funding would accelerate the business and what measurable progress it would enable.
Do not spend all your time preparing a pitch deck while ignoring product development and customer conversations.
A 30-Day Startup Execution Plan
You do not need to complete every phase perfectly before moving forward. This schedule gives you a practical starting point.
| Period | Primary focus | Expected output |
|---|---|---|
| Days 1–3 | Choose a problem and define your target customer | One-page problem brief |
| Days 4–8 | Interview potential customers | Interview notes and problem patterns |
| Days 9–12 | Compare solutions and test a simple offer | Initial validation evidence |
| Days 13–20 | Build the smallest useful solution | Working MVP or manual service |
| Days 21–25 | Test with early users | Feedback and usage observations |
| Days 26–30 | Test pricing and review results | Initial business model and next-step decision |
This is a working schedule, not a guarantee of product-market fit in 30 days. Some problems require much more time to validate, and a good founder changes the schedule when the evidence demands it.
The point is to finish the month with something more valuable than a completed playlist: direct customer knowledge, a tested solution, and a better understanding of what to do next.
How Much Time Should You Spend Watching Videos?
Use the original Startup School playlist as a reference library.
Do not turn it into a prerequisite for action.
A practical starting allocation is:
- 20% of your time: Learning, reading, and reviewing relevant lessons.
- 60% of your time: Building, customer interviews, sales, and experiments.
- 20% of your time: Reviewing results, making decisions, and planning the next week.
This is a suggested operating rule, not a researched universal optimum. Adjust it to your stage. If you are still discovering the problem, spend more time with customers. If you already have a usable product, spend more time improving it and acquiring users.
Follow one simple rule: every learning session should lead to an action.
After a lesson on customer interviews, schedule interviews. After a lesson on MVPs, define the smallest testable product. After a lesson on fundraising, decide whether fundraising is even necessary right now.
If a video does not help with the problem you are currently facing, save it for later.
The Real Goal: Build Evidence, Not a Video-Watching Streak
The biggest benefit of Startup School is not memorizing startup terminology. It is learning how to make better decisions under uncertainty.
You do not need to know every detail about fundraising to interview your first customer. You do not need to understand every technical architecture to test whether someone needs your product. And you do not need a finished company strategy to take the next sensible step.
You need a problem worth investigating, a willingness to speak to customers, the ability to build or deliver a simple solution, and the discipline to learn from what happens.
The sequence is straightforward:
Identify a problem → Talk to customers → Test a solution → Deliver value → Learn from usage → Improve the business.
Return to the videos whenever they help you make a better decision. Otherwise, close the tab and get back to work.
Your first objective is not to become an expert at startups.
It is to create something useful for a real person, learn whether that value matters, and use the evidence to decide what comes next.