Y Combinator’s “The First 10-person, $100B Company” was a Request for Startups (RFS) theme, not a promise that a particular Fall 2025 batch would produce a $100 billion company. Its central question is more useful: can a tiny team, using software and AI aggressively, create value at a scale that previously required thousands of employees?
For founders in India, this is a demanding but practical lens. The country offers deep technical talent, large digital markets, cost-efficient operations, and problems that remain underserved across education, healthcare, finance, logistics, government services, and global business software. The opportunity is not to add a chatbot to an existing workflow. It is to redesign the workflow around an intelligent product.
What the 10-person, $100B thesis means
The thesis combines three ideas:
- Small teams can now build much more. AI coding tools, cloud infrastructure, APIs, and automated operations reduce the cost of shipping and maintaining software.
- The product must be globally scalable. A large outcome usually requires a market bigger than one city, one customer segment, or one low-margin service category.
- Automation must be structural. A company with ten employees cannot rely on manual implementation, customer support, sales, or operations at scale.
This does not mean founders should keep headcount artificially low. It means every hiring decision should increase the company’s ability to serve more users, generate more revenue, or improve the product disproportionately.
A strong idea might look like an AI-native back-office system for a global industry, an agent that completes complex regulated workflows, or a product that gives a small business capabilities previously available only to large enterprises. The bar is not simply “uses AI”; the bar is ten-person economics with billion-dollar market potential.
Why India is a strong testing ground
Indian founders can use local complexity as an advantage, provided they avoid building a product that cannot travel beyond India. Multilingual users, fragmented supply chains, digital public infrastructure, price-sensitive customers, and compliance-heavy sectors expose difficult product problems early.
For example, a team building an AI education product must understand curriculum variation, exam preparation, parent trust, language, and distribution. A team building financial software must handle identity, fraud, reconciliation, and regulatory obligations. These constraints can create durable product capability—but only if the company treats them as engineering and distribution problems rather than temporary obstacles.
Founders should ask:
- Can this product reach international customers without a large services team?
- Does India provide a unique data, distribution, or workflow advantage?
- Will the product become more valuable as usage increases?
- Can the company serve customers at a price that supports venture-scale growth?
Students and first-time founders can also start earlier than they assume. This guide to starting an AI company as a student in India covers practical routes from problem selection and prototyping to finding an initial user base.
What YC is likely to look for
YC applications are strongest when they show evidence rather than ambition alone. At an early stage, evidence may include a working prototype, repeated user behaviour, design-partner commitments, revenue, or a founder’s unusually deep understanding of the problem.
Explain four things clearly:
- The problem: Who experiences it, how often, and what they do today.
- The insight: Why existing products or processes fail.
- The product: What the user can do now, not merely what the roadmap promises.
- The proof: What users have tried, paid for, retained, or requested repeatedly.
Avoid inflated market-size slides and generic claims about transforming an industry. If your product is an AI agent, demonstrate the complete task it performs, the tools it can use, the human approval required, its error rate, and the economic value created. A short product demo with real users is often more persuasive than a long presentation.
Designing a 10-person company
A small team needs a narrow initial wedge and unusually strong systems. Before hiring, identify which work can be automated, self-serve, or eliminated.
Product and engineering
Build a reliable core workflow before adding model features. Use evaluation sets, logging, fallback logic, permissions, and human review where mistakes are costly. For customer-facing AI, measure task completion, latency, accuracy, retention, and cost per successful outcome—not just model quality in isolation.
Distribution
A 10-person company cannot depend on dozens of sales representatives. Choose a repeatable channel: product-led growth, a focused founder-led sales motion, strategic partnerships, communities, or embedded distribution through an existing platform. For sales-driven products, study AI-powered personalized sales automation and adapt the principles to your own segment rather than copying a tool stack blindly.
Operations and support
Make onboarding, billing, permissions, reporting, and support observable and increasingly self-serve. Enterprise customers may need implementation help initially, but every repeated manual step should become product functionality, documentation, or automation.
Hiring
The first hires should remove a fundamental bottleneck: product reliability, distribution, domain expertise, or customer success. Generalists with strong ownership are valuable, but regulated markets may require specific compliance or sector knowledge. Headcount is not a growth strategy; a better product and repeatable distribution are.
A practical application and validation plan
If you are applying to YC or testing this thesis in 2026, use a four-week sprint:
1. Week one—customer discovery: Interview a tightly defined user group. Document current workflows, costs, workarounds, and buying authority.
2. Week two—prototype: Build the smallest end-to-end product that completes one valuable task. Do not begin with a broad “AI platform.”
3. Week three—live usage: Put it in front of users. Track completion, errors, repeat usage, and the time or money saved.
4. Week four—business proof: Charge where possible, secure design partners, quantify outcomes, and write a clear account of what changed.
If your product is a personalised assistant, review both building a personalised AI assistant with the Claude API and the security implications of local-first operating systems for privacy. These are especially relevant when handling sensitive Indian user data or enterprise information.
Your application should state what you learned, including negative results. YC partners are evaluating founder speed, judgement, technical ability, and insight—not a polished fiction of certainty. Be precise about what is built, who uses it, how often they return, and what you will do next.
The risks behind the thesis
Extreme efficiency can become a trap. A tiny team may underinvest in security, reliability, compliance, hiring, or customer relationships. AI-generated code does not remove the need for architecture, testing, monitoring, and responsible data handling. Nor does automation create demand where none exists.
The right goal is not to remain at ten people forever. It is to build a company where every additional employee expands capability rather than compensating for a broken process. If the business eventually needs a larger team, that can be a sign of scale—not failure.
Bottom line
YC’s first 10-person, $100B company thesis is best treated as a design constraint: start with a painful problem, build an AI-native workflow, prove repeated value, and create distribution that does not grow linearly with headcount. Indian founders have strong raw materials for this approach, but global ambition must be matched by global product quality, trust, and execution.
Use the thesis to sharpen your company—not to manufacture a valuation story. A small team that solves one important problem exceptionally well has a stronger chance than a large team pursuing a vague market narrative.