3 Lessons From Our Y Combinator Experience

Hi all. I’m Nicolas, a co-founder at Lume, and I’m excited to be sending out our first newsletter 👾 (this emoji will be heavily overused as I begin to post more content about Lume; I am for some reason very attached to it as a symbol of our startup) … 👾

First, thank you for all of you who signed up to be a part of our journey through this newsletter. We will be sending out a mix of content, ranging from insights during our work in the AI and Data space, opinions on AI breaking news and new technology, and our experiences as YC startup founders.

If you ever have any questions, comments, requests, or think we can be of any help to you, do not hesitate to reach out to myself or my co-founders, Robert and Nebyou. My email is attached as a “reply-to” (hopefully).

Let’s get started - Episode 1!

———-

Lume is a startup in the winter 2023 Y Combinator batch (YC W23). We are building AI software to generate and maintain custom data integrations.

I want to talk about three key lessons that stood out for our founding team during our time there. If you're a startup founder (or interested in startups) looking to learn about iterating quickly and succeeding in YC, you've come to the right spot.

Before we get started: If you're a minority founder and got invited for a YC interview, I invite you to reach out to me to ask for advice! The batches are growing in minority founders – but we still have a long way to go.

1) Embrace Unscalability

Starting off, software engineers often have a penchant for perfection. We want to create scalable and reusable code from the get-go. It’s very difficult to stray from that habit, because it was ingrained in us as a great habit to build. But, paradoxically, this habit is a crutch when building an initial prototype. We quickly learned to focus on scrappiness rather than scalability in the initial prototyping phase.

We received a key piece of advice from one of our YC partners: “At each stage of your company, you may as well scrap all your code and rewrite the entire codebase. Meaning, a different codebase for your prototype, MVP, $10K MRR, $100K MRR, and so on.” The implications and priorities from your code can be extremely variable depending on your stage. If you try to maintain the codebase throughout, you’ll find that your “robust” codebase is the equivalent of many houses duct-taped on top of each other, rather than one skyscraper.

There are a few quick takeaways here

• Do not be married to your codebase. The priorities needed from your code will change, and full refactors will be necessary.

• Build what you need for the stage of your company. For our prototyping phase, we needed to iterate and learn as quickly as possible. This meant creating scrappy code, validating our ideas, and moving forward. When implementing the validated ideas on your production environment, this is when you focus on robustness.

• Your codebase should be one singular skyscraper (no matter how tall), not many houses duct-taped on top of each other. Maintain your code accordingly.

Your early product will likely undergo many iterations. The emphasis should be on speed, flexibility, and the ability to incorporate feedback rapidly. We learned to be as scrappy as possible so we could quickly change our code based on real-time insights. Once your prototype starts evolving into your production MVP, that's when you shift priority on scalable code. Today, as we migrate to onboarding clients, our production code is robust and scalable for iterating on future features. In short, do things that don’t scale, then scale them.

This lesson expands to many aspects of building a startup, not just code. Here is Paul Graham’s piece on doing things that don’t scale.

2) The Minimalist Validation Framework

In our quest to solve our customers’ problems, we engineers often rush into coding each new feature idea to demo it to users. Especially for seasoned engineers, this route can be rather “fast”, as they are fast programmers. However, there are always faster methods. The goal is to prototype with as little code as possible, which is directly correlated with optimizing time spent validating your ideas.

Those in the space are very familiar with “vaporware”: features with no backend, or mock-up designs on tools like Figma. Creating vaporware can help you gauge user interest and collect feedback, without the upfront cost of creating a fully-fledged program. We used this approach to validate Lume’s lineage graph. Had it been deemed unnecessary, we would have saved a considerable amount of development time.

And, you can always strive for less code. Founders even use screenshots of examples they find online of similar features, to see how it resonates with their users during demos. Users don’t mind that it’s not built yet - as long as it is delivered by when your customer expects it. This cuts prototyping time significantly - use it!

3) Hang out with founders

A part of your role as a startup founder, one that doesn't always make it to the job description, is meeting with other founders. Our founder network has been a cornerstone of our growth at Lume.

In the early days, we were busy building, and we missed many opportunities to get to know other founders at Y Combinator events. This was a mistake. Our founder friendships (or more traditionally, our “network”) are not just about socializing; it's about gaining insights, validating hypotheses faster, and unblocking roadblocks more efficiently. Fellow founders also understand many trials you go through yourself, so they serve as a great sounding board for discussing difficult moments and decisions.

We course-corrected this halfway through our Y Combinator batch and gained not only invaluable insights but also lifelong friends. Today, they continue to be valuable friends and partners: our New York office today is shared with 4 other Y Combinator teams! We learn from each other daily and love it.

That's all for now - thank you for reading. We loved our YC experience, and we very highly recommend it.

Now, go build something people want.

Appendix

Lume Website
Any requests for what we should write about? Email us!