five musings about building a good product

reflections on a year at Codeium

I recently hit my one year at Codeium. When I joined the Codeium team, we were a small but mighty team of around 20, enough to squeeze in a living room and do company-wide standup every day. Since then, we’ve scaled almost 10x in size and launched a rocket ship product called Windsurf. The journey’s been extraordinary and I want to share some recurring musings that stick with me.

Embracing endlessness

As a small company challenging massive incumbents, death is the default. It’s a saying I love because it instills a healthy level of urgency. If our ambitions don’t exceed that of resourceful competitors, how do we expect to compete?

Everyone’s agency needs to be amplified to feel like no problem cannot be solved. And when no problem feels impossible, suddenly it feels like you’re tackling an ocean of problems.

The number of projects feels endless, but there’s an end to all projects. It ties to breaking things down. When done right, frequent completion and seamless collaboration aren’t the only benefits. Morale is the biggest benefit. It’s rewarding feedback and it propels enough momentum to the next milestone.

When we started working on Windsurf, saying it was a monumental effort is an understatement. To get it done, we broke it down into practical milestones. From conception to release:

1. We got VS Code to build on our machines

2. We then got our existing extension functionality working like autocomplete and chat

3. We then replaced Chat with Cascade

4. We then got it into internal dogfooding

5. We then went into a closed beta

6. We finally launched on November 13th

The next milestone was never more than two weeks away. Progress was constantly felt and we even had internal dashboards to see how internal adoption was going on. Seeing company adoption was exciting, especially knowing how picky many of our engineers are with their dev environment. Even though the laundry list of tasks felt never ending, our belief in the product’s potential was always high due to the frequent feedback from progress.

Unconventional is conventional

It’s great to have a team that embraces the unconventional. Just because something’s never been done, doesn’t mean that we shouldn’t do it. In fact, it’s encouraged if the idea has merit.

For example, when we were first exploring ways to show code changes inline in VS Code, there was no documented way of doing this. It was as frustrating as walking into a restaurant with an uncooked Michelin star meal—the restaurant has all the tools to cook it for you but it doesn’t offer it as a service. If there had to be a way, what would it be?

I spent some time digging into open-source code and found that it was possible to do CSS injections and render images. I proposed the crazy idea of using CSS injections to position a canvas image rendered on the user’s machine. This is like trying to eat rice with a fork—it works and it’s better than having no utensils (but obviously not as optimal as a spoon or chopsticks). Not only was it suboptimal, I was pretty confident no one has ever done it before. But at its core, it was a solution that could sort of cook the Michelin star meal.

We got excited about the idea, we prototyped it, and we shipped it to our VS Code extension. It involved a lot of detailed visual tweaks to make it feel native and although it wasn’t perfect, it was exciting to build for a few reasons:

• It solved an important problem

• Nothing like this existed on VS Code at the time

• Calculated risks and unconventional approaches were encouraged at Codeium

And then we eventually sunsetted it after it accomplished its goal.

It’s creatively stimulating to work with people who embrace crazy ideas. There’s a little bit of excitement whenever a brainstorm converges towards a crazy idea, especially knowing that the crazy idea can be a reality loved by users. No one wants to throw away an uncooked Michelin star meal.

Not all crazy ideas are great, but if approached right, they will be either a great learning or highly impactful. Airbnb is a great example of this—if it solves a problem but it sounds crazy, the best path forward is to try it out. And look at where they are today.

Make exponential bets

How many 10% improvements are needed to make a 100x improvement? 49 of them.

Incremental improvements make sense when distribution has been achieved. A 1% improvement on 500M ARR is a 5M jump, an impressive feat for many. When I was a PM on Uber’s Marketplace Pricing team, I wondered why our OKRs goals were low single digit percentages. But when converted into dollar value, the impact was arguably large.

When building at a high-growth startup, the most important decision is often the strategic one: what will you bet on? In a vacuum, the expected value between optimizations and big bets might be the same due to the risk of big bets. The benefits of a crowded space is that there’s market validation for new features at zero cost. This increases the expected value of some bets which informs what’s the right balance of optimizations and big bets for a team to prioritize.

Most big bets don’t work out. Part of the science of building a rocket ship is how quickly you know that your ship isn’t a rocket ship. This is why pivoting is so common among startups. At Codeium, we have a lot of work that’s in the graveyard, both shipped and unshipped. Before my time, Codeium used to be a GPU infrastructure startup. Now we build an agentic IDE called Windsurf.

In practice, this is hard. There’s an urge for optimization, perfection, completion, and more for the current focus. But every second spent building a diminishing project is a second lost for the next exponential bet. It’s the sunk-cost fallacy in practice. It’s demoralizing to abandon work, but it’s a necessary evil in order to work on the most important thing.

When we were first developing Windsurf, our extension’s Chat feature was going to be a core feature. We had worked on it for over a year at that point and users already loved the product. When we were evaluating Windsurf’s launch strategy during its development, we wondered if our minimal prototype of our agent Cascade had the potential to surpass Chat. We could either spend all of our time on a feature that already had a lot of validation or bet on something nascent. We took the 10x bet, cut Chat, and launched with Cascade. And then Cascade went viral. Users loved it way more than Chat. At that point, we knew we found something special with our bet and we’re excited to continue making waves with it.

Invest in skilled people you can trust

When I was first interviewing for Codeium, I did an onsite with the team. I vividly remember walking into the office and felt a focus similar to when I walked into Figma’s office during my internship with them. Everyone was locked in. It oozed passion. Afterwards, I joined the regular 1pm walk and I was disarmed by how low ego, friendly and smart the team was (s/o to Mehul). We talked about a counter-intuitive physics problem involving stacking jengas on the edge of a table (a crazy amount of nerd rizz if I had to be honest). It was hard not to feel compelled to work with the team.

Fast forward to today, it seems obvious. I love and trust the team and love working with them five days a week in person. Over the year, we tried many projects, some of which fell flat. While the product’s ride may have been bumpy, the journey building with my team has been consistently fulfilling. It makes sense to not focus on what you can’t control because consumer-facing products are a coin-flip. Instead, we’ve grown an amazing team with an even more amazing culture. The core idea is that prioritizing a good team over immediate product success is more sustainable. To win, you need a sustainable strategy, not just an impressive demo for Twitter or metric to show off to investors. Luckily, a great team can get you an impressive product and sustainable metrics and growth.

Interning at Figma was my first time seeing what it’s like to be surrounded by a small team filled with great builders that are even better human beings. As a more experienced operator today, it’s clear that the culture and energy at Codeium is special. It doesn’t surprise me to see how fast we built Windsurf and improve the product post-launch to where it is today.

When I work with people today, the most important thing to me is if I can trust them. It’s easiest to work with someone who’s trustworthy and skilled. Two-way trust is so much more important than individual cracked-ness. Trust needs to be intentionally built. And trust is most easily built with people who are high integrity, low ego, and are eager to learn.

Beyond just being great human traits, it also scales very well. I’d much rather a trustworthy team of 10 than 10 individual cracked engineers who can’t work with each other when working towards one common goal. Trust in good people is the path to creating a team that’s greater than its individuals and I believe we’ve found that at Codeium.

Flawlessness over magic

Flawlessness is invisible. The product should just work as expected as reliably as pencil and paper. Its experience should blend with the intuition a user already has, and deliver what’s promised. The best outcome for a user is if they have nothing to say and have everything to entrust to the product.

The challenge is that when building a product, there’s always two competing interests: bugs and features. On one hand, if you only fix bugs, the product doesn’t push the innovation boundaries and fails to stay ahead of competition which leads to low growth. On the other hand, if you don’t fix bugs, it leads to a flawed user experience which causes churn.

In the age of LLMs where engineering velocity is faster than ever, there’s a higher emphasis on bugs than in the past. Notably, there are more failure modes due to LLMs, many of which are hard to catch by the system. All users would prefer to have a deterministic path to the best possible experience every time.

Once we launched Windsurf and saw the feedback pouring in, we saw how important flawlessness was to our users. This wasn’t a surprise but it emphasized the urgency of flaws. A magical moment only happens once, but flawless experiences last.

This has been a guiding principle in how we approach product development and especially in our many releases. A release won’t flop if we omit a few feature requests, but it will flop if we introduce or don’t fix existing bugs. Quality comes from the lack of bugs, not from the existence of features. As we continue developing Windsurf, the fine balance between features and bugs is always top of mind.

The journey over everything

A good journey is measured by its worst days, not its best. Culturally, Codeium’s fostered a culture of collaboration, ownership and excellence. In such an environment, good decisions are celebrated just as much as good outcomes. A failed exponential bet or a sunsetted feature is just as important to the journey as a successful product launch.

The first year with Codeium has been great for me and I couldn’t be more excited for the next ones. If building a product loved by its users in a collaborative environment excites you, we’re hiring! And if you’re interested in a taste of the future of software development, try Windsurf today.