YC S11 was one of the most formative experiences of my career. The specific format — compressed timeline, intense peer cohort, the forced clarity of preparing a Demo Day pitch — taught me things about how to build that I still use. I recommend the program to founders who fit the profile.
And yet, I've watched Nordic founders take the YC model home and apply it in ways that didn't make sense in the context they were building in.
The issue isn't that the YC model is wrong. It's that it was designed for a specific context, and some of what it teaches is context-dependent in ways that aren't always clearly marked. Building in Copenhagen in 2026 is not the same as building in San Francisco in 2011, and the differences matter for how you apply the lessons.
Here's the filter I use when thinking about what transfers.
What transfers completely
Talk to users. Now. More than you think you need to.
This is the YC lesson that is universally true regardless of ecosystem, stage, or sector. The specific way Paul Graham delivered it — the discomfort you feel when you realize you've been building based on assumptions rather than conversations — doesn't change based on geography.
Nordic founders, if anything, are more susceptible to this failure mode than US founders. The Nordic engineering culture values building things that are technically correct. The assumption that technical correctness implies product-market fit is wrong everywhere, but the cultural inclination toward craft over validation is particularly strong in environments where engineering excellence is the dominant norm.
Do more customer discovery than you're comfortable with. Do it before you build and while you build. This transfers.
Make something people want, not something that is interesting.
The distinction between "interesting" and "wanted" is a fundamental filter, and Nordic founders underweight it. The Scandinavian engineering tradition produces a lot of technically interesting projects. "Technically interesting" and "product that people will pay for repeatedly" are different things, and the distance between them is sometimes large.
This lesson transfers completely.
Launch faster than feels right.
YC's pressure on speed to launch is partially context-dependent (the San Francisco startup ecosystem has norms about launching early that don't exist in the same way in Copenhagen), but the underlying principle — that your mental model of user behavior is almost certainly wrong and that actual launch data is better than extended development — transfers.
Nordic founders tend to launch later than US founders. This is partly cultural (the Scandinavian approach to quality; the norm against presenting something before it's ready), partly contextual (the smaller initial market makes a bad launch more costly), and partly a genuine miscalibration. The miscalibration part is worth correcting.
What transfers, but needs translation
Growth is the only metric that matters (early).
YC's specific emphasis on week-over-week growth as the primary metric is designed for the phase where a company is trying to find product-market fit quickly enough to raise a seed round or get to Demo Day. In that phase, the advice is correct: nothing else is a reliable leading indicator of whether you're on the right path.
The translation for Nordic building: the metric still matters, but the timeline can be different. If you're building for enterprise customers in regulated industries — where a single customer relationship might take six months to close and twelve months to generate meaningful revenue — week-over-week growth is not the right measurement cadence.
The principle (obsess about a growth metric, adjust everything to move it, use it as a constant diagnostic) transfers. The specific implementation (weekly revenue growth, weekly active users) needs translation for the specific market.
Demo Day pitch format.
The three-minute Demo Day pitch — problem, solution, traction, team, ask — is a useful template for any early-stage pitch. The problem-first structure especially transfers; US and European investors both respond better to founders who can articulate a specific, concrete problem than founders who lead with the solution.
But the Demo Day pitch is calibrated for a US investor audience whose frame of reference is entirely North American. A Nordic founder pitching a problem in maritime logistics, pharmaceutical compliance, or Nordic-specific infrastructure needs to add a market education layer that a Demo Day pitch doesn't have room for. The format needs translation.
What doesn't transfer, or transfers badly
The "do things that don't scale" heuristic, applied too broadly.
YC's "do things that don't scale" advice is specifically calibrated for the very early phase of finding product-market fit, where you want to develop extremely close relationships with a small number of users to understand the problem deeply before automating. It's brilliant advice for that phase.
Nordic founders who apply this heuristic to operational processes — using the "it doesn't scale but that's fine at this stage" logic to avoid building good operational infrastructure — end up with organizational debt that's harder to pay off than they expect.
The distinction I try to make: customer acquisition can be manual and not scale in the early phases. Internal operations should be designed to scale even when small, because the cost of retroactively adding operational infrastructure is higher in Nordic teams (which tend to be more stable and have more organizational memory embedded in informal processes) than in Silicon Valley teams (which turn over faster and are more accustomed to process change).
The move fast and break things culture, applied without context.
This wasn't explicitly a YC teaching, but the culture around it was present in the ecosystem. It doesn't transfer well to regulated industries (where "breaking things" can have regulatory consequences) and it doesn't transfer well to Nordic organizational norms (where trust is earned slowly and broken quickly).
Nordic founders who internalize the "move fast" ethos and then apply it to customer relationships, enterprise integrations, or data handling in ways that violate the implicit norms of their customer base are burning trust that took years to accumulate and will take years to rebuild.
Demo Day as the destination.
YC's structure orients everything toward Demo Day — the compressed three-month timeline, the preparation process, the investor dinners, the pitch. This is extremely useful for getting to a fundable state quickly.
The problem is that some Nordic founders internalize "fundable state" as the destination rather than as a means to an end. The fundraise is not the milestone. The company is the milestone. This sounds obvious and is not obvious when the entire structure of the experience is oriented toward a fundraising event.
The YC model is good. Paul Graham's writing on startup building is the most consistently correct writing on the topic I've found. The batch experience — working alongside other founders, the peer learning, the forced accountability — is genuinely valuable.
Apply it with the filter that some of it is context-dependent. Talk to your users. Make something people want. Launch faster than feels right. Obsess about a growth metric.
And build a company that can survive without the round. That one transfers too.