Blog
Six weeks ago, I had a crazy idea to build and open-source a project that used as many YC W23 companies as possible. In honor of demo day, I’m excited to launch the project, and with it, some takeaways.
Eventbase is a simple platform to create and manage in-person events. Think Partiful or Luma, but much less cool.
Admittedly, it’s nothing special on its own, but it provided me with an excellent blank canvas to experiment with all of the different products. In the remainder of this post, I’ll cover the full set of companies, my observations, and my suggestions for how founders can improve their onboarding and developer experience.
Without further ado, let’s take a look at the companies:
- Buildt helps developers quickly search, understand, and extend their codebases. I used it as a chatGPT-like companion within my IDE to ask questions and refactor code.
- Frigade provides onboarding infrastructure for developers. I used it to give new users a quick tour of the product.
- Highlight is an open-source, full-stack monitoring platform. I used it to replay and debug user sessions.
- Infisical is an open-source secrets management platform. I used it to manage secrets locally.
- Inquery is an open-source platform for webhooks and more. I used it to send myself a Slack message each time a guest RSVPs for an event.
- Mirrorful is a simple, open-source design system framework. I used it to manage my design system.
- Noya is a product design tool that automatically generates designs and code from wireframes. I used it to design the first version of the landing page.
- Outerbase is an interface for your data. I used it to visualize guest lists for upcoming events.
- Pyq makes it easy for non-ML engineers to add ML features to their applications. I used it to generate an image based on the title of the event.
- Resend1 is a new email API for developers. I used it to send guests a beautiful confirmation email when they RSVP to an event.
- Teclada is a browser-based terminal. I used it as a replacement for the terminal.
- Type is an AI-first document editor. I used it to generate a product spec for my project and come up with new feature ideas.
The rest of the stack includes Supabase2, Next.js, Vercel, Google Places API, & shadcn's ui library.
A learning experience
There are pros and cons to working with so many different tools in a single project. As a developer, I tend to gravitate towards trying new things as often as possible, but not to this extent. The sheer number of tools I was trying to work with caused a few headaches.
First, it was harder than expected to determine a good use case for every tool I wanted to try. There are a lot of interesting LLM, API, and security companies in the batch (Metal, Fern, Escape are all super interesting), but unfortunately they just didn’t really work with my existing stack. I also found it pretty difficult to manage API keys and environment variables. Coincidentally, one of the companies I was using as part of the project (Infisical) helped with that.
On the other hand, it was really interesting to have the opportunity to try out so many new tools. After going through a dozen websites, onboarding flows, docs sites, and support channels, I’ve learned a thing or two about what it takes to nail developer experience.
The website matters
They say not to judge a book by its cover, but in my experience, I found a high correlation between the quality of a company’s website and its overall product.
A sleek, well-crafted website is often a great proxy for overall product sense and attention to detail. Furthermore, a good website is clear, concise, and actionable. In reality, I only spend a minute or so on a website before deciding if I want to use the product.
Take Resend, for example, a new email API for developers. When I first saw their website, it felt like pure magic. From the default dark mode, to the 3D Rubik's cube, it was clear to me that they want their users to feel something. Their simple tagline and clear call to action also made it easy for me to understand what they do and how to get started.
Optimize time to value
Speaking of getting started, I also learned a ton about these companies from their onboarding experiences. For bottom-up, developer-focused products, few things are as important as time to value. I’ll be honest – I’m pretty busy, a bit lazy, and easily distracted – but I don’t think other developers are too different. Dev tools should be optimized for users to reach the “aha moment” in as little time and with as little effort as possible.
A good example of time to value is Pyq. On their website, it’s incredibly easy for prospective users to browse through the models they offer and try them out right there. Within a few seconds, I was able to see exactly what I needed to get started.
Reduce all friction
Time to value is important, but an even more critical milestone for dev tools is the time to integrate. In my experience integrating these twelve companies, I was reminded that documentation is just as important as the product itself.
Good documentation is the difference between a user successfully integrating or giving up. First and foremost, all docs should allow users to copy code snippets with a click of a button. Something as simple as requiring users to select the code with their cursor introduces a significant margin for error. Second, all starter code should be as dynamic as possible (e.g. autofill the user’s API key, prompt, etc.). If not, at least make it super obvious when things need to be replaced (<YOUR API KEY HERE> is a lot better than “example-api-key-123456789”).
You’d be surprised at how much time I wasted trying to debug things, when it turned out I just didn’t realize I was missing an API key. Lastly, starter code snippets should be fully functional. Even better, there should be some open-source examples available on GitHub.
One of the more delightful experiences I had on this front was with Highlight, an open-source monitoring tool. It took me all of ~2 minutes to integrate Highlight into my Next.js application. They dynamically populate the project id in the starter code for authenticated users (blurred out in the image above), so there’s no need to jump to another page, copy, and paste it yourself.
Keep it simple
All of that said, there are some aspects of onboarding that can’t be improved with better documentation. Installation and setup can be make or break for dev tool or infrastructure companies.
In a perfect world, I should be able to run npm install once and be good to go. I don’t want to download Docker, hunt down a bunch of missing dependencies, or create some bloated file structure just to start using a new tool. I also expect that any out-of-the-box integrations (e.g. GitHub, Vercel, Supabase) required to use a product are battle tested and ready to go. It’s also important that a product works well with existing tools. If I'm only able to get a tool to work at the expense of the others, I'm unlikely to use it.
Inquery, a toolkit for PostgreSQL databases, was one of the standouts in this department. All I had to do was copy my database information from Supabase and I was good to go.
Obsess over customers
On that note, there are an infinite number of things that can go wrong with software, especially when a company is building and shipping like these twelve were. In my experience, the best founders are maniacally focused on making their users successful.
My advice to founders is to give the same attention to your support as you do to your product in the early stages of your company. Watch Slack/Twitter/Discord like a hawk, jump in instantaneously, and engage one-on-one with users who are asking for help. Take every question and piece of feedback you receive and use it to make the product better. One of my favorite parts of working on this project was meeting the founders through their support channels.
While many of the YC founders were incredibly responsive and helpful, Frigade really stood out to me. Any time I asked a question, Eric or Christian would jump in within seconds (literally), offer to jump on a Zoom, read my code, and help me out.
Ship, ship, ship
Last but not least, I can’t understate the importance of shipping velocity. Throughout the last three months, these companies shipped a lot of code. Many of the features I’m using in this project didn’t exist at the start of the program. In fact, several of them were added within the last six weeks. Shipping is the most effective way to learn alongside your customers.
When I first met Mirrorful, they didn’t yet support Tailwind CSS. Within about a week, they shipped it, reached out to me with thorough documentation, and offered to help me get it working.
Closing thoughts
One of my core values at base case capital is always building. Building is how I learn new things, build intuition about interesting opportunities, and ultimately engage with founders on a deeper level. Although I’ve admittedly been sleeping a lot less in the last six weeks, the euphoria I felt when I successfully sent my first Resend email, saw the first image generated by Pyq, or watched my first session replay on Highlight was well worth it. The weekend troubleshooting sessions with Eric & Christian at Frigade, late night DMs with Mitch & Eric at Inquery, and philosophical conversations with Ali from Buildt have helped me gain profound respect for what it takes to get a company off the ground. I’ve had more fun over the past six weeks working on this project than ever before in my career.
If you’re building a product for developers, let’s work together to integrate it into Eventbase. It’s fully open-source, so feel free to clone it, play around, and submit a pull request.
Thanks to Hassan El Mghari, Tyler Angert, and shadcn for their help on the project and Sarup Banskota, David Yamnitsky, Isabella Tromba, and Ankur Goyal for their feedback on this post.