How is life post YC?

The two types of quality

Consistency is the key

Trying something new

Where we are and what’s to come


One of the things I was most curious about during our batch was how life would be after Demo Day.

I compiled some of the learnings from my own experience and asked other Y Combinator friends from various batches, so you can get a feel of what happens after YC.

> *“Many founders look back at their YC journey as the fastest and most intense period of their startup journey, which is ironic because you usually attend YC in the first 1 year (when you are small, confused, and have no repeatable processes). A startup should only ever get faster - adding more employees should add output/velocity, adding another feature should unlock more customers, more time means better processes. YC gives founders a reason to create this DNA inside their company, and then after the batch it’s up to the founder to continue the mindset.”*
>
> **— [Paul Copplestone](https://twitter.com/kiwicopple), [Supabase](https://supabase.com) (S20)**

## 1. It doesn't get easier

We joined YC for the Winter 2023 batch, which means that our program went from January until April 2023.

During that time, we used to have around 146 new sign ups every week, which seemed like a lot for us to handle as a small team of 3 people.

<figure>
  <img src="/static/img/posts/how-is-life-post-yc-a.png" class="post-image-full" alt="New sign ups per Week from Jan 2023 - Apr 2023">
  <figcaption class="post-image-caption">New sign ups per week from Jan 2023 - Apr 2023</figcaption>
</figure>

After Demo Day was over and we were done with fundraising, we kept pushing really hard.

Today, we have around 3,464 new sign ups every week.

<figure>
  <img src="/static/img/posts/how-is-life-post-yc-b.png" class="post-image-full" alt="New sign ups per Week from Jan 2023 - Jan 2024">
  <figcaption class="post-image-caption">New sign ups per week from Jan 2023 - Jan 2024</figcaption>
</figure>

One of the reasons why we were able to grow is because of an immense sense of urgency.

> “The hardest thing is to keep momentum, especially with a growing team. During YC, you have to deliver on a weekly cadence. Nobody wants to be the bad performer in their group. After YC, there is nobody providing that pressure. So you need to find other ways to generate momentum. Some companies adopted regular Launch Weeks, we ship bi-weekly at Raycast. Right after YC, we wrote [monthly focus documents](https://www.raycast.com/blog/focus-document) and assigned projects to everybody. This shared ownership helps to work with agency.”
>
> **— [Thomas Mann](https://twitter.com/thomaspaulmann), [Raycast](https://www.raycast.com) (W20)**

I thought that after YC, things would calm down, but it was quite the opposite.

So, if you think the Demo Day goal is hard, wait until you see the Series A goal.

> *“You need to stay focused on your current ICP, and center everything around (e.g., pricing, messaging, sales, engineering, marketing) while still remembering your long-term vision, and think BIG.”*
>
> **— [Vlad Matsiiako](https://twitter.com/matsiiako), [Infisical](https://infisical.com) (W23)**

## 2. Some of your friends’ startups will pivot or die

YC is a sprint towards Demo Day, but building your company is a marathon.

> *“I used to tell my wife, "oh after X (round, customer, product launch, whatever) I'll have more time, things will be less busy, etc." As you progress with the companies, the challenges change, but the urgency and the momentum matter even more. You now have more customers, more revenue, more investors, so the stakes are higher and the work is still plentiful.”*
>
> **— [Tom Hacohen](https://twitter.com/TomHacohen), [Svix](https://www.svix.com) (W21)**

During that marathon, you'll see some of your friends pivoting to a completely new space, and that's a good thing. It means that they were able to identify problems early and change quickly.

You'll also see some of your friends disappearing - some because their business is booming, but others because it's not.

It's always a great idea to help and support others, that's what this community is all about, but make sure to put the oxygen mask on yourself first.

> *“It’s ok to feel like you don’t have everything figured out or need to pivot after the batch. Many companies did, including us. We didn’t get into what we’re doing now until after the batch after ours ended.”*
>
> **— [Han Wang](https://twitter.com/handotdev), [Mintlify](https://mintlify.com) (W22)**

## 3. Create your own little bubble

YC does an amazing job of separating people into different groups and sections. This is great because you meet companies that are at a similar stage and serving similar customers.

> *“Try to stick to the two-week goals, like in group office hours, to keep the pace high for as long as possible. Funnily enough, I always wonder what our group partners would think of many of the decisions we make after batch. It helps me think about whether it's a good idea or not. It's like this: If I were to book an office hour with Tom today and tell him about our idea/plan, what would his reaction be? And I can literally see his face and feedback in front of my eyes.”*
>
> **— [Philip Isik](https://twitter.com/PhilipIsik), [Tiptap](https://tiptap.dev) (S23)**

Once YC ends, they recommend you to keep doing office hours with your section. In our case, most of the startups in our section ended up pivoting, having founder breakups, or not growing at the same pace, which makes it hard to relate and help each other.

So we ended up creating a shared Slack channel called #founder-therapy with really close founder friends, where we give each other updates, ask questions, and support each other.

More than an accountability group, you need a safe space to share the challenges of being a founder.

> *“What helped us maintain the pace was to religiously continue with our two week goals and sync monthly with another company from the batch that was close to us.”*
>
> **— [Lucas da Costa](https://twitter.com/thewizardlucas), [Briefer](https://briefer.cloud) (S23)**

## 4. Being in SF is as important during YC as post YC

Many people come to San Francisco during the batch because of the in-person experience.

I was one of them. After living in Los Angeles for 8 years, I packed my things and rented an Airbnb to stay only for 3 months with my wife and 1-year-old daughter.

Once Demo Day was over, we debated if it was worth it to stay. We were paying 2x as much here for 1/2 of the size and comfort.

Still, we made a decision to stay.

And the main reason is to simply increase our odds of success.

Seibel and Dalton recorded a video on [“Does Your Startup Need To Be In San Francisco?”](https://youtu.be/ZqGOCF4O6ks?si=nnKbTxzFgfSgVMgC), so I won't go too deep on this subject, but you should definitely consider staying after the batch.

Of course, there are exceptions. Every team is different, and some companies are building products for a specific market, so they don't need to be here.

## How about you?

If you've been through YC, what have you learned after the batch? What advice would you give?

If you haven't been through YC (yet), what are other things you are curious about?

I compiled some of the learnings from my own experience and asked other Y Combinator friends from various batches, so you can get a feel of what happens after YC.


The Japanese define quality in two ways:

* atarimae hinshitsu (当たり前品質)
* miryokuteki hinshitsu (魅力的品質)

Understanding the difference between them is the key to building products that users love.

## atarimae hinshitsu (当たり前品質)

*Atarimae hinshitsu* is the idea that things should work the way that they are supposed to.

It's a **purely functional requirement** and is satisfied when the product completes the job that it was designed to create. For example, an IKEA chair meets the *atarimae hinshitsu* quality expectation because it's made to sustain and fit a person of average height and weight. Being **reliable and robust** is a significant component of quality, and there is elegance in things working according to their function.

<figure>
  <img src="/static/img/posts/quality-ikea.jpg" class="post-image-full" alt="IKEA Chair">
</figure>

## miryokuteki hinshitsu (魅力的品質)

*Miryokuteki hinshitsu*, on the other hand, is the idea that things should have an aesthetic quality.

It's basically the **kind of quality that fascinates you**. This could include things like visual appearance, sound, or anything that gives personality to a product. For example, a Herman Miller chair could be considered *miryokuteki hinshitsu* because it goes **beyond its functional requirements**. There's a distinct touch, smell, texture, and design that makes it unique; it's a “special refuge from the strains of modern living," as they say. These aspects bring added value to the product and make it desirable.

<figure>
  <img src="/static/img/posts/quality-herman.jpg" class="post-image-full" alt="Herman Miller Chair">
</figure>

## quality applied to software

As developers, we are often asked to build software products that have good quality, but what does that *really* mean? Is software quality only about meeting a certain number of functional requirements? What about the other parts of a software company? Let's explore how this is applied to real-world scenarios.

## product that works vs. product that inspire

Developers may disagree on many things, but there's one thing that almost everybody will agree on — **Jira sucks**. The reason for that is not because [Jira](https://www.atlassian.com/software/jira) is slow, because the design is outdated, or "feature x" is missing. The problem is the entire product mentality. Jira introduces more process. It encourages micro-management. **It disrupts flow.** And any product that disrupts flow is inherently bad for users.

This doesn't mean that Jira is a failure. In fact, Jira is a *massive* success from a sales perspective. It's a software that serves the needs of middle management, or, at least, the needs middle management thinks it has. What are those needs? Metrics. Being able to make charts, graphs, and reports for the next-higher level of management, so they can say that their team is productive and isn't falling behind. Jira is focused on *atarimae hinshitsu* and nothing else.

<div class="side-by-side">
  <figure>
    <img alt="Jira" src="/static/img/posts/quality-jira.png"  class="side-by-side-img">
    <figcaption class="side-by-side-caption">Jira</figcaption>
  </figure>
  <figure>
    <img alt="Linear" src="/static/img/posts/quality-linear.png" class="side-by-side-img">
    <figcaption class="side-by-side-caption">Linear</figcaption>
  </figure>
</div>

When you look at [Linear](https://linear.app/), you see the complete opposite. It's modern, clean, and has all the features you need without being bloated. On top of having a traditional web app, they also built a pretty fast desktop experience. They know that developers will use the app daily and will probably spend more time on it than project managers or stakeholders who are only using it to report progress once a week. That's why they added keyboard shortcuts for almost every single interaction.

They are able to create *miryokuteki hinshitsu* by focusing on the user, not the buyer.

## marketing that works vs. marketing that inspires

It's common for companies to change their go-to-market strategy from bottom-up to top-down model after achieving some level of success. When [Braintree](https://www.braintreepayments.com/) started, it was about serving individual developers ([screenshot from 2014](https://web.archive.org/web/20140101045849/https://www.braintreepayments.com/)). Nowadays, all you see are *"Contact Sales"* buttons everywhere.

This approach can definitely work if you're targeting executive leaders at specific company sizes. Still, one thing is sure — developers don't want to enter your *"marketing funnel,"* they don't want to be considered a *"qualified lead,"* and they don't want to be *"converted."* All they want is to try a product without having to speak to a salesperson first.

<div class="side-by-side">
  <figure>
    <img alt="Braintree" src="/static/img/posts/quality-braintree.png"  class="side-by-side-img">
    <figcaption class="side-by-side-caption">Braintree</figcaption>
  </figure>
  <figure>
    <img alt="Stripe" src="/static/img/posts/quality-stripe.png" class="side-by-side-img">
    <figcaption class="side-by-side-caption">Stripe</figcaption>
  </figure>
</div>

[Stripe](https://stripe.com) is an overused example, but there is still a lot to learn more about them. The company was founded in 2010 and raised a total of [$2.3B in funding](https://www.crunchbase.com/organization/stripe/company_financials). They serve millions of businesses, including dozens of Fortune 500 companies. And yet, even after all these years, they still haven't changed their strategy.

They continue to push the envelope when it comes to UI and UX. They continue to build elegant APIs and refined documentation. They continue to include code snippets on their landing page because they know that's what developers want to see.

They also know that developers will not download a gated PDF e-book, so they publish all these in-depth guides on their website. They know developers will not register for a special webinar, so they make all their sessions available online. There's no *"lead magnet"* strategy behind these initiatives, and that's what creates trust.

## recruiting that works vs. recruiting that inspire

Every big corporation like [PayPal](https://paypal.com) has the exact same Jobs page. You see a list of open positions, filter by a department or specific region, and then read an uninspiring job description. When you finally decide to apply for a role, you receive a soulless, automated message in your email inbox. After weeks of silence, you may get a chance to speak with a recruiter. If you don't get lucky, you may get another template message saying you're not a good fit for the role.

<div class="side-by-side">
  <figure>
    <img alt="PayPal" src="/static/img/posts/quality-paypal.png"  class="side-by-side-img">
    <figcaption class="side-by-side-caption">PayPal</figcaption>
  </figure>
  <figure>
    <img alt="Plaid" src="/static/img/posts/quality-plaid.png"  class="side-by-side-img">
    <figcaption class="side-by-side-caption">Plaid</figcaption>
  </figure>
</div>

Knowing how frustrating that process can be, some startups find a creative approach to reach more candidates and cut through the noise. [Plaid](https://plaid.com), for example, continues to attract great engineering talent with its unique approach to recruiting. They have an API-first product, so they lean on that narrative and showcase their culture by allowing engineers to apply by API.

## engineering that works vs. engineering that inspire

Talented developers tend to gravitate towards others based on what they build. That's why announcing new features is one of the most effective ways to attract engineers and create a sense of *“we’re always shipping.”* Changelogs are the perfect place to explore that.

When you look at what products like [Alfred](https://alfredapp.com) are doing to communicate changes, you'll notice the same monotonous and repetitive format. There's a version, there's a date, and there are a bunch of bullet points. This format works, and the information is there, but it's not engaging and doesn't evoke any special feeling.

<div class="side-by-side">
  <figure>
    <img alt="Alfred" src="/static/img/posts/quality-alfred.png"  class="side-by-side-img">
    <figcaption class="side-by-side-caption">Alfred</figcaption>
  </figure>
  <figure>
    <img alt="Raycast" src="/static/img/posts/quality-raycast.png" class="side-by-side-img">
    <figcaption class="side-by-side-caption">Raycast</figcaption>
  </figure>
</div>

[Raycast](https://raycast.com), on the other hand, is a team that not only wants to show value but also wants to create a pleasant feeling on their changelog. They describe every change in detail because they know that changelogs are made for humans, not machines. They have engaging titles and polished screenshots because they know the magic is in the details. They understand [what makes a good changelog](/what-makes-a-good-changelog) and leverage that to amuse readers and spark interest.

As with anything in life, when you invest extra time in an area typically neglected by others, you generate an element of surprise and enchant. That's what *miryokuteki hinshitsu* is all about.

## what are you optimizing for?

Quality is not about trade-offs; quality is about philosophy. You can choose to achieve both *atarimae hinshitsu* and *miryokuteki hinshitsu* so that a product will meet users’ needs and be delightful to use.

However, when thinking about quality, it's crucial to have self-awareness. You have to look at **what you** are optimizing for as an individual and see if that matches with **what your team** is optimizing for. If there's a mismatch, there's a high chance that you'll end up with a suboptimal product.

For more on this topic, I recommend watching [Jiro Dreams of Sushi](https://en.wikipedia.org/wiki/Jiro_Dreams_of_Sushi), a documentary directed by David Gelb, and [How to Build Products Users Love](https://youtu.be/12D8zEdOPYo), a talk by Kevin Hale.

*Special thanks to [Briza Bueno](https://twitter.com/brizabueno), [Bu Kinoshita](https://twitter.com/bukinoshita), [Carol Moreschi](https://github.com/carolmoreschi), [Jonni Lundy](https://twitter.com/jonnilundy), [Michael Grinich](https://twitter.com/grinich), [Shawn Wang](https://twitter.com/swyx), [TK](https://twitter.com/wordsofteekay), [Vitor Fernandes](https://twitter.com/vitorviesi), [Ygor Costa](https://twitter.com/ygorhiroshi), and [Zeh Fernandes](https://twitter.com/zehf) for reviewing this article before it was published.*

<figure>
  <img src="/static/img/posts/quality-end.jpg" class="post-image-full" alt="Man cooking sushi">
</figure>

The Japanese define quality in two ways — atarimae hinshitsu and miryokuteki hinshitsu. Understanding the difference between them is the key to building products that users love.

Stories. Thoughts. Opinions