ExpertsFMPeter Steinberger: "Fun Is Velocity"
Y Combinator Startup Podcast · August 11, 2026
5 Selected Lessons:
heuristic · 2 priority · 2 framework · 1
Fun is velocity
Source
Y Combinator Startup Podcast — Peter Steinberger: "Fun Is Velocity" (August 11, 2026) · at 22:07 ▸ · at 24:33 ▸
When this applies
when deciding which internal state to optimize for to maximize output speed on any creative or technical project
The takeaway
Rank enjoyment of the work above almost everything else as a leading indicator and driver of output quality and speed.
Why it works
Enjoyment sustains focus, risk-taking, and iteration speed; when a builder loses joy, work shifts to defensive, incremental tasks (like adding config options) instead of meaningful progress.
One level up
Treat your own motivational state as a primary operational lever, not a side effect to be managed around.
Where it stops holding
This stops working when 'fun' is confused with avoiding necessary but tedious work (security, support) that the project genuinely needs, or on teams where one person's fun isn't aligned with collective priorities.
Detail
hierarchy:
- having fun building
- velocity/output
- shipping visible improvements vs config-only weeks
rationale: The weeks I enjoyed building, the product got visibly better. The weeks I didn't, we shipped config options. It's hard to compete with someone who's just there having fun.
In their words
The weeks I enjoyed building, the product got visibly better. The weeks I didn't, we shipped config options. Question five.
Three things to remember: fun, gut, focus
Source
Y Combinator Startup Podcast — Peter Steinberger: "Fun Is Velocity" (August 11, 2026) · at 24:33 ▸
When this applies
when a builder needs a short, memorable ranking of what to optimize for across a long, chaotic project
The takeaway
When distilling lessons from a complex experience, rank a small number of durable internal commitments above situational tactics.
Why it works
Each priority addresses a different failure mode observed in his own story: losing motivation (fun), ignoring intuition under analytical pressure (gut), and getting distracted by noise/media (focus).
One level up
Durable guidance should be few, memorable, and oriented at internal discipline rather than external circumstance.
Where it stops holding
This stops working when external constraints (funding, team dynamics, regulation) dominate outcomes regardless of personal fun/gut/focus, or when 'annoyance-driven' ideas don't scale into real markets.
Detail
hierarchy:
- Don't stop having fun — find the ultimate driver to get the best ideas
- Listen to your gut, and fix the things that annoy you — it might become the next big thing
- Stay focused — live in the future, build what's missing, keep shipping even when criticized
rationale: If you only remember three things... another podcast is not what will make you win. Live in the future, build what's missing. And when they write your obituary, keep shipping, it confuses them.
In their words
If you only remember three things. Number one, don't stop having fun. Find the ultimate driver so you can get the best ideas. Number two, listen to your gut. And also, fix the things that annoy you. It might just become the next big thing. And number three: stay focused.
Risk-weighted code review
Source
Y Combinator Startup Podcast — Peter Steinberger: "Fun Is Velocity" (August 11, 2026) · at 31:11 ▸ · at 38:40 ▸
When this applies
when deciding how closely to scrutinize any output your team or tools produce, given limited reviewer time
The takeaway
Allocate scrutiny proportionally to blast radius and difficulty of self-verification, not uniformly to all changes.
Why it works
Review depth should scale with the cost of being wrong: scary/critical systems carry high downside if broken, while cosmetic/UI changes are self-verifying by inspection and low-risk if subtly wrong.
One level up
Treat review/oversight as a risk-management budget to be spent selectively, not a uniform gate applied everywhere.
Where it stops holding
This stops working when a seemingly low-risk area (e.g., UI) secretly touches shared state or security boundaries, or when a project moves to a context (like a larger company) with stricter code-reading requirements.
Detail
procedure:
- Classify the touched system by risk: scary/critical systems get a close read
- For UI or cosmetic changes, glance over and verify visually that it looks correct
- Use time-to-completion as a signal: if a task that should be small (e.g., a drag interaction tweak) takes unexpectedly long (e.g., three hours), investigate closely
- Otherwise trust accumulated gut feel from observing size and nature of the change
benchmarks: {"anomaly_signal":"small tweak taking 3 hours instead of expected time flags closer review"}
rationale: I see code review more as risk management ... part of it is just like you develop a little bit of a feeling how long something should take.
In their words
I think I was really early in deciding that I don't read all the code. I see code review more as risk management.
Strong emotional reaction as PMF signal
Source
Y Combinator Startup Podcast — Peter Steinberger: "Fun Is Velocity" (August 11, 2026) · at 2:46 ▸
When this applies
when trying to tell if an early prototype has product-market fit before metrics exist
The takeaway
Look for intensity of reaction, not just approval, as the earliest signal of demand.
Why it works
Indifference means the thing is forgettable; strong emotion (positive or negative, including anger when denied access) indicates the product touched something people actually care about.
One level up
Signal before scale: find qualitative proof a few people care deeply before you try to prove many people care a little.
Where it stops holding
This stops working when the strong reaction is driven by novelty/shock rather than actual sustained use or willingness to pay/adopt.
Detail
situation: Peter built a magical-feeling WhatsApp relay agent but couldn't get anyone on Twitter to understand why it mattered.
decision: He created group chats with friends, let them talk to the agent directly, and watched their reactions instead of trying to explain it.
outcome: Every demo produced a strong emotional reaction — amazement, fear, or anger when told 'not yet for you' — which he read as a clear PMF signal and kept iterating.
lesson: Direct hands-on exposure that provokes strong emotion, especially frustration at being denied access, is a more reliable early signal than verbal explanation or polite interest.
In their words
So if that's not an indicator to have product market fit, I don't know what is.
Your dependency's business model is your business model
Source
Y Combinator Startup Podcast — Peter Steinberger: "Fun Is Velocity" (August 11, 2026) · at 15:40 ▸
When this applies
when a product's core experience depends on a single upstream vendor's pricing or access policy
The takeaway
When you build on someone else's platform, their business decisions become binding constraints on your own, whether or not you planned for it.
Why it works
Optimizing deeply for one provider creates a hidden dependency: if that provider changes terms (pricing, access, availability) with little notice, the dependent product inherits that risk instantly and has no time to adapt.
One level up
Map your critical dependencies and treat their incentives and stability as part of your own risk surface, not an externality.
Where it stops holding
This stops working when the dependency is genuinely commoditized or diversified enough that losing one provider doesn't materially change the product's value.
Detail
rule: Your dependency's business model is your business model.
threshold: 24 hours notice before subscription access was disabled was not enough time to change course.
rationale: The harness was optimized for Opus for a long time because it worked best; when the subscription access was pulled, there was no real buffer to adapt, and alternative open-weight models weren't yet strong enough to absorb the shock.
In their words
So maybe write this one down. Your dependencies business model is your business model.