đź“š

My learnings as a (YC) founder

Tags
Startups
Published
Author
I’ve been chasing the startup dragon since 2017, and now 6 years later, have decided to reflect on the most important learnings of that time.
Some may seem obvious, some not. Not may be specific to industries in which I’ve opereated in, but can be extended to others by analogy.
This serves as a remind for myself, and hopefully a guide for the next generation of founders.
The advice here is roughly sorted by both my experience over time, as advice for the age of a startup.
There is nothing worth skipping or skimming here, everything here is immesely valuable and has been learned the (very) hard way. Please do not learn this the hard way as well.

Do not “play business”

Every move you take should have a goal and have actionable evidence for why this process or action is in place.
A fatal mistake I made in the first year being a founder and leading a team was to copy what I had learned from other companies. These companies were far larger than I was, moved far slower than a startup needed to, and had very different product requirements.
As a 2-person development team we spent far too much time on testing, building internal frameworks, making everything a microservice, arguing about structure and architecture, and more. Part of this was having the wrong team for the job, but part of it was my mistake in putting too many processes in.
  • Jira had uncessary complexity
  • Spent far too much time on CI/CD
  • Microservices caused more harm than good
  • Overengineered far too much
  • Used additional technology for any reason I could find, rather than optimizing for less
  • Hire people because it feels right, only hire when it hurts
The solution here is to slim down as far as possible, remove as many meetings and processes as possible, make sure that everyone is aligned, nobody is doing anything for processes’ sake. Also known as “a founder mindset”.

Make something people want

While this conveniently is the slogal of YC, it’s 100% true. This goes in hand with “playing business”, as many people will just build a startup and pour resources into building a company that makes something nobody wants.
A solution in search of a problem is the #1 killer of startups.
You not only need to have conviction that the world wants (or needs) what you are making, but you need to have proof. You need to have identified a want or need that people are extremely eager to throw money at, and you need to have a solution that satisfies that.
Talk to 25+ potential customers, look for patterns, build for that. If you cant find common ground between them, then your solution is not worth building.
This will also help you gague the market size and potential size of your company.

Your YC partners are correct… at least mine were

Shoutout to Diana, Dalton, Rich, and Nicolas. Every time they said something it was correct. Whether they thought we should pivot for X, Y, or Z, whether they thought reaching X would result in Y, etc.
They know what works, just listen to them, trust me. Their time and advice is the most valuable thing to a startup.
I only have 2 regrets from the S22 batch:
  1. I didn’t move out there for the batch
  1. I didn’t take Dalton seriously on pivoting 2 months earlier than we ultimately decided to for the exact reasons he predicted
And they aren’t just lucky in their words, they’re consistently correct.

Elon Musk’s 5 pillars are shockingly correct

Whether you hate him, adore him, or anywhere between, the man knows how to rally a team. The following principals are how I broke out of “playing business”, and vaulted into 30-150% MoM growth in all categories for many consecutive months. These pillars should be followed in order of decreasing importance.
  1. Make requirements less dumb: do you really need X? Do you need to automate this edge case? Are you thinking as a user or engineer?
  1. Delete the part or process: The best PR is the one that removes more code than it adds. More code, processes, etc. add more complexity which means more problems. Always prefer to remove. Chances are you can already cut 10-20% of your code or processes you have.
  1. Simplify or optimize: Can you make existing systems simpler? Is there
  1. Accelerate Cycle Time: We reduced our dev cycles from 2 weeks to 1 week. We now get far more done in a month. People will take as much time as they are given for a task, so give them less time and they will give you more concise solutions.
  1. Automate: You don’t need to automate every case. Many failure cases can easily be handled manually, or telling people to reach out to support. Stop spending hours on an edge case that 1/10,000 customers have until you are hitting it every other day, or it’s so unbelievably painful to your business that the time to recover from 1 instance is less time than preventing it in the first place. An example of this would be for handling failures when setting up payout accounts, tell them to contact support rather than automating every possible failure case.

Do not over hire

I’ll repeat this again.
Through our first venture, Ultimate Tournament, we hired to a team of 4 (including founders). By the Ultimate Arcade (what we got into YC with, before pivoting in late July), we were at 6. Come 2023, we are again at 4 and are moving faster than ever.

Vet your contractors like a founder

You should have multiple glowing reviews, all paid nearly exactly the same price per hour.
Fixed rates are BS, their predictions are always shorter than actuality.
Any “discounts” they give you just mean that they will give you an inexperienced team that will consistently fail in every way possible. You get what you pay for, there are no real discounts.

Be wary of the fragility of building in the shadow of giants

In the case of Tangia (YC S22), we built a tool for viewers to send “interactions” like on stream. This included AI TTS (with characters or your own custom voice!), AI Image gen (Stable Diffusion), Overlay Memes (videos), drawing on the stream, and more.
 
Some of these learnings could be extended to mobile apps building for their respective stores, but it is clear that Twitch’s policies are far more restrictive, and processes are fatally flawed.

Malicious Compliance

This can work both ways.
The giant can use their vague and ambiguous wording, or “Reserve all rights” to pick and choose how they apply policies. While this is unethical, anti-competitve, and probably illegal, what are you going to do about it if you don’t represent a signficant portion of their revenue? You won’t be spending millions over 2 years so sue them certainly.
Sometimes you have to maliciously comply back.

What will kill you

  • Inconsistent policy enforcement — or “dart-board policy enforcement” as I like to call it
  • Obscenely long response times from support — you are stuck to moving as fast as the giant. Startups benefit from their immense speed.

Short policies and terms are a red flag

This can only mean one of two things:
  1. The company has not seen bad things yet and they will enforce things they haven’t written down yet
  1. There are lots of unwritten rules that you will only discover through painful interation that they refuse to write down (pick any corporate sounding reason you like)
 
All of these pains compound, and are exponentially amplified by incompetent management and compliance representatives. The experience will be obscene, and should probably be classified as anti-competitive. But again it doesn’t matter to them, they are too big to fail at this point.
 

A summary by GPT-4

I thought it fun to bring AI into the mix, so here’s a summary:
Click the arrow to reveal
đź“‹
GPT-4’s summary:

Do not "play business"

  • Avoid copying larger companies and focus on what's essential for your startup
  • Streamline processes, reduce meetings, and maintain a "founder mindset"

Make something people want

  • Identify a problem and create a solution that people are willing to pay for
  • Talk to potential customers and analyze the market size

Your YC partners are correct

  • Trust the advice of experienced partners, as they have valuable insights

Elon Musk's 5 pillars are shockingly correct

  • Follow these principles: make requirements less dumb, delete parts or processes, simplify or optimize, accelerate cycle time, and automate

Do not over hire

  • Maintain a lean team to move faster and more efficiently

Vet your contractors like a founder

  • Seek multiple positive reviews and avoid fixed rates or "discounts"

Be wary of the fragility of building in the shadow of giants

  • Be aware of inconsistent policy enforcement and long response times from support
  • Short policies and terms can be a red flag for unwritten rules or inexperience