ExpertsFMBuilding A Global AI Startup From India
Y Combinator Startup Podcast · March 16, 2026
5 Selected Lessons:
heuristic · 3 interpretation · 2
Enter late markets only with a product that is head-and-shoulders better, then brute-force distribution
Source
Y Combinator Startup Podcast — Building A Global AI Startup From India (March 16, 2026) · at 7:34 ▸
When this applies
when entering a market late against entrenched, fast-growing competitors
The takeaway
If you're behind, your product must be dramatically — not marginally — better, and you must pair that with an aggressive, scalable distribution tactic.
Why it works
A product that is only marginally better won't overcome incumbents' head start and word-of-mouth; distribution mechanisms like influencer marketing can rapidly compensate for a late start once product superiority exists.
One level up
Catching up requires compounding two different unfair advantages (product and distribution) rather than relying on either alone.
Where it stops holding
This stops working when the market has strong lock-in/switching costs regardless of product quality, or when influencer-driven users don't convert to the target persona.
Detail
rule: Enter late only with a product head-and-shoulders above existing options, and use a broad-based but persona-targeted distribution push (influencers) to convert the right users.
threshold: Product quality bar: 'head and shoulder above what exists in the market today for people to take notice.'
rationale: Being confident the product was strong let them focus resources entirely on distribution speed rather than further product iteration.
In their words
Even if your product is really, really strong, and fundamentally, I think you'll have to enter the market with a really, really strong product, which is head and shoulder above what exists in the market today for people to take notice.
Don't engineer around problems the next model generation will solve
Source
Y Combinator Startup Podcast — Building A Global AI Startup From India (March 16, 2026) · at 5:27 ▸ · at 14:49 ▸
When this applies
when deciding whether to build a workaround for a limitation of an underlying platform/technology that is rapidly improving
The takeaway
Triage engineering effort by forecasting which limitations are likely to be solved upstream versus which are durable problems you must solve yourself.
Why it works
Because foundation models improve fast and unpredictably, investing heavily in scaffolding around a specific current weakness risks wasted engineering once the next model generation removes that weakness.
One level up
In a fast-improving ecosystem, build only for the gaps that will persist, and progressively hand more decision-making autonomy to the improving substrate.
Where it stops holding
This stops working when you guess wrong about which capability will improve, leaving a critical gap unaddressed while waiting for a model that never arrives on your timeline.
Detail
rule: Don't spend engineering effort hardening against a current-model weakness if you expect the next model generation to fix it; progressively loosen your control harness as models get more capable, since the data shows more model autonomy improves outcomes.
threshold: Observed: 'the more control you give to the model decision making, the better the harness gets' as models get larger/more efficient.
rationale: Keeps engineering focused on durable differentiators instead of transient model weaknesses.
In their words
Initially, our hardness was very strict and we would tighten it up. And slowly, what we were observing is that as these models are getting larger and larger, more efficient, the more control you give to the model decision making, the better the harness gets.
Mandate every team member to do customer support regularly, even at speed cost
Source
Y Combinator Startup Podcast — Building A Global AI Startup From India (March 16, 2026) · at 25:50 ▸
When this applies
when a team risks building for an abstract user rather than a real one, especially across cultural/geographic distance
The takeaway
Force direct customer contact for every contributor on a recurring cadence, even when it feels costly in the short term for a resource-constrained team.
Why it works
Direct, recurring exposure to real customer requests (even pulling a best engineer off feature work) builds tacit understanding of user needs that can't be replicated by secondhand reports, closing the gap between a remote team and a global, culturally distant user base.
One level up
Proximity to the end customer must be deliberately engineered when the team and customer are geographically/culturally separated.
Where it stops holding
This stops working when customer support requires specialized skill a generalist team member can't provide (e.g., legal/compliance issues), or when pulling engineers off core work causes unacceptable delivery delays.
Detail
rule: Everyone talks to a customer once or twice a week; even a small team pulls a best engineer onto full-time customer support rotation.
threshold: Explicitly called 'a really hard decision' given a 12-person engineering team needing to ship fast, but done anyway.
rationale: Built customer empathy from day zero, including handling requests in French/German via AI translation despite being an India-based team serving Western users.
In their words
It was a really hard decision for us because, you know, you're a really small team. You need to ship really fast. And then move like one of your best engines out to do customer support was really hard.
Coding is only 20% of the job — the moat is user understanding and production delivery
Source
Y Combinator Startup Podcast — Building A Global AI Startup From India (March 16, 2026) · at 14:49 ▸ · at 32:29 ▸
When this applies
when a platform/infrastructure provider threatens to subsume your application-layer business as it becomes more capable
The takeaway
A capability provider's horizontal power doesn't automatically substitute for an application layer's job of continuously matching rising user ambition with product depth.
Why it works
Taking an app to production and continuously meeting growing human ambition requires deep, ongoing understanding of user needs that a model provider, focused on general capability, won't necessarily prioritize or excel at.
One level up
As a general-purpose capability commoditizes, differentiation shifts to how well you understand and serve the specific, evolving needs of your users.
Where it stops holding
This stops working when the model provider itself builds a comparably deep, user-specific application layer, eliminating the application company's distinct value.
Detail
approach: Reframe the competitive threat: coding capability is a small fraction of value; the larger fraction is production-readiness and evolving user needs (distribution, growth, user management).
signals:
- model capability keeps increasing
- human ambition/complexity of requested apps keeps rising at a similar rate
- your custom harness measurably outperforms raw foundation models
rationale: As models get more capable, the scope of what users want to build expands correspondingly (Jevons paradox), keeping the application layer's work from shrinking.
In their words
Our view is that I think the coding aspect is only 20% of the job, right? I think taking an app to production is really, really hard.
Jevons paradox applied to software engineering jobs and roles
Source
Y Combinator Startup Podcast — Building A Global AI Startup From India (March 16, 2026) · at 14:49 ▸
When this applies
when a productivity-multiplying technology makes a unit of work cheaper, and you want to predict whether total demand for that work shrinks or grows
The takeaway
When a technology drastically lowers the cost of an activity, expect demand for that activity to expand rather than simply reduce headcount, per Jevons paradox.
Why it works
Cheaper, faster production of software increases the total volume of software people want built (expanding market, e.g. non-developers becoming builders), and simultaneously lets roles combine (PM/designer/engineer in one person), so observed job/role counts can rise even as per-task effort falls.
One level up
Productivity gains from new technology tend to expand a market's scope before they shrink its labor force.
Where it stops holding
This stops working when the activity has a hard ceiling on total demand (satiation), in which case efficiency gains do reduce total labor needed.
Detail
approach: Interpret rising tool power as expanding the addressable market and the ambition of what people attempt, not merely automating existing headcount away.
signals:
- number of software engineering job postings increasing despite more powerful AI tools
- internal teams observing 5-6 person work done by 1-2 people, implying expanded scope per person rather than fewer total tasks
- rate of expected shipped software per week continually rising
rationale: This is a 'hedonistic adaptation'/Jevons paradox: more powerful tools raise expectations of output rather than reducing total work demanded.
In their words
I mean, there's another graph that I was sure shared recently. It's just like the number of software engineering positions available is actually going up, right?