Lessons from four years of building a startup

(Originally published in Portuguese on Substack.)

Next month marks four years since I joined Openlayer. I was the first employee and joined shortly after the founders went through Y Combinator in 2021.

I've learned a lot along the way. This post is my attempt to put some of those lessons into words. I've grouped them into general lessons, engineering, and product. Feel free to jump around.

General

Let your work guide what you learn

I come from an academic background, so during my first few months at Openlayer, I was always looking for books or papers to learn from. This was essentially the self-directed version of how I learned at university: if you wanted to learn something, you enrolled in a course and read the recommended books and papers.

I'd start by picking a topic (say, "MLOps"), and then read books that seemed interesting. I was learning, but there was a problem: the knowledge was disconnected from my day-to-day work. I struggled to apply it.

Eventually, I realized that a better approach was to let my work guide what I studied. Instead of starting with a topic, I started with something I needed to do. With that in mind, I'd look for resources to help me learn: books, blog posts, or conversations with AI. If only one chapter of a book was relevant, I'd read just that chapter.

You don't have to read an entire book to learn something useful.

Read broadly

This partly contradicts the previous lesson. Still, I've learned that it's useful to read beyond the topics directly related to your work. Biographies and fiction, in particular, have helped me see connections and make what I believe were better product decisions.

I came across this passage in Hayao Miyazaki's Starting Point: 1979–1996, about how reading widely helps you create original work:

But if I asked them to draw a picture of how they imagined a chaika (a flying boat in Future Boy Conan) would look in flight, they could only imagine something based on what they had seen on TV before. And so I wouldn't be able to use their work.

To draw a chaika flying in a truly original way, you would need to have read at least one book on the history of aviation, then use your imagination to build on what you learned.

If you immersed yourself in books about the history of airplanes, you would come across Igor Sikorsky. He was the man who, in 1913, built the world's first four-engine biplane and flew it over Russia. (He later emigrated to the United States and, in 1942, invented the first single-main-rotor helicopter.) When Sikorsky flew his four-engine plane over Russia, he became known for having a meal on board and then, when one of the engines failed, holding on to a wing strut and standing outside the cockpit. With the wind blowing straight into his face, he personally and anxiously checked the engines. I think Sikorsky captures what it really means for a human being to fly. And it is from that image, of someone simply wanting to fly, that a good illustration emerges. It doesn't come from imitating something seen long ago in an animated TV series, from a plastic model kit, or even from the experience of flying in one of today's hermetically sealed passenger planes.

— Hayao Miyazaki, translated from the Portuguese excerpt.

Be patient and keep showing up

There are stories of overnight success in startups, and they do happen. But most of the time, that's not how it goes. Over the past four years, I've worked countless weekends, had meetings that lasted until 3 a.m., and put in plenty of long days.

And where did all that code and those product decisions end up?

In the trash. Completely discarded.

I didn't know that at the time. After all, who would skip an important occasion to build something that would be thrown away a few months later?

In startups, these cycles of building and tearing things down are normal. Finding product-market fit is an iterative process, and mistakes help inform the next iteration. But those cycles also give you perspective. At the time, the things I was working on felt extremely urgent and important.

The lesson is to be patient, stay consistent, and focus on the work itself rather than its potential rewards. Many people jump ship out of frustration after a year or two. Some lessons take longer to learn.

There are no shortcuts. It's hard for everyone.

Almost everything is chaotic at first

Early products are simple, break in unexpected ways, and have plenty of rough edges. At that stage, comparing them to mature products isn't useful. It's unrealistic to expect the same level of polish.

For example, these were some of the main components of Openlayer's platform during the first year:

The product was interesting, but it wasn't the kind of thing a large, established company would buy.

Looking back, I think the chances of an enterprise buying something like this were close to zero. We didn't know that at the time. The product gradually improved until it became something we could sell. There's still a lot to improve, but we're a long way from that first version.

In his memoir, Play Nice But Win, Michael Dell writes that some of the computers they sold in Dell's early days caught fire. Imagine selling someone a computer and getting a call saying their house almost burned down because of it.

Even Dell's products were imperfect in the beginning.

Small teams are surprisingly productive

In Brazil, I see a lot of startups hiring too many people too early. Until we raised our Series A, the entire Openlayer team could fit in a car. We landed some huge customers with a very small team.

With fewer people, it's easier to build trust and get by with fewer processes. You can also pay people better and have less turnover.

Engineering

Learn from other people's implementations

Many of the features you'll build have already been implemented in other products. You can learn a lot by reading their code, if it's open source, or trying to reverse-engineer the implementation from their documentation.

You don't need to reinvent the wheel. Find out how others did it. Understand it, adapt it, and improve it.

Use keyboard shortcuts

If you're an engineer at a startup, you probably spend most of your day at a computer. A big part of using it quickly is minimizing how often you reach for the mouse. That means learning shortcuts and, potentially, using apps that make it easier to control your computer from the keyboard.

Here are some of my favorites. I use a Mac.

Apps:

• Raycast: mostly for finding files and apps, and accessing my clipboard history.
• Rectangle: for moving and resizing windows.
• Wispr Flow: I'm still experimenting with it, mostly for dictating prompts to AI and writing.

Shortcuts:

• ⌘ + Tab to switch between apps, and Control + ←/→ to move between desktops.
• ⌘ + W to close the current tab or window.
• ⌘ + Delete to delete back to the beginning of a line, or Option + Delete to delete the previous word.
• Editor shortcuts, in something like Cursor: ⌘ + F to search, Option + ↑/↓ to move lines, ⌘ + D to select and edit repeated occurrences, ⌘ + L to add context to chat, ⌘ + P to navigate between files, and ⌘ + Shift + P to open the command palette.

Automations:

I've built a few Raycast extensions for repetitive tasks. One is a shortcut to generate commit messages, which I explained in this tweet.

This might seem like a lot at first. Eventually, you stop thinking about it. It becomes automatic.

Use AI effectively

With AI, generating things, whether text or code, is fast. Verifying them takes longer. Don't produce AI slop and leave someone else with the burden of reviewing it. Opening a sloppy PR that needs several rounds of review is one example.

That said, AI is extremely useful, both for writing code and for helping you think.

For coding, I've been using it in two ways: synchronously, with Cursor, and asynchronously, with Claude Code. I might explore this in a future post.

Trace down, then learn up

I think the best way to understand a feature in a large codebase is to "trace down, then learn up." I learned this approach from Mitchell Hashimoto's post on contributing to complex projects.

First, trace down: follow the feature's call path from the outside in. In a web app, for example, you might start at the API endpoint, follow the functions it calls, then the functions those call, and so on. Write down the function names and the files they live in.

During this step, don't worry about understanding the implementation. Just map the path through the code.

Once you reach the bottom, learn up. Follow your notes in reverse. Start by understanding the innermost function, then work your way back to the top.

You can use AI to help with both steps.

Product

Think about demand

I came across this idea in Demand-Side Sales 101. Most people building products spend too much time thinking about the supply side: what their product offers users. It would often be more useful to spend that time thinking about the demand side: what users are looking for.

Here's an example from Openlayer's documentation. I've written almost all of it, going back to the earliest versions, and I've always tried to follow good documentation practices. But after learning about demand-side thinking, I realized that almost the entire structure reflected the supply side. The navigation was organized around our product's features and concepts.

When users open the docs, though, they aren't necessarily thinking in our terms. I took some time to think about how they'd approach it and reorganized the content around that. The current version is much more focused on their demand: the things they're trying to do and the questions they have.

You can apply the same principle to different parts of your product.

Story over completeness

When you're demoing your product, it's much better to tell a good story that highlights its main features than to try to show everything it can do.

When you've built something, it's tempting to walk people through every feature. But I think a good demo is like the table of contents of a good book. You get a sense of what it's about, and a few chapters make you curious.

If users have questions or want more detail, they'll ask. Assuming, of course, that you pause and give them the space to do so.

You don't need user feedback all the time

One of Y Combinator's mantras is to constantly "talk to users." It's good advice, but often, users have opinions, not truths.

If you ask someone whether they prefer A or B, they'll pick a side. But is their opinion inherently better than yours or someone else's on your team? In general, I'd say no.

After spending enough time in a market, you develop the ability to "simulate" users in your head. If you really make the effort to think like a user, you'll find that you can answer many of your own questions.

Build and tell people about it

A rhythm I've learned and try to follow is to build something, then talk about it publicly. Just because you built it doesn't mean people will notice. You have to tell them.

For example, after building Openlayer's MCP server, I posted a demo on Twitter/X. The video got almost 5,000 views.

Another time, I wrote a tweet about a problem I solved by building the "Openlayer assistant," an experimental feature in the platform. That tweet got more than 200,000 views.

To be honest, I can't point to anything specific that happened because of either post. But those posts, and a few others, may have been how some people first heard of Openlayer.

The internet has expanded the number of people you can reach. You're no longer limited by where you live. Use that.

There are many more lessons, but this post is already long. I don't think I could write about everything anyway. I still need more time to process some of what I've experienced over these past four years.

Being part of Openlayer's journey from the beginning has been a privilege. There are ups and downs, of course, but helping build something I believe should exist, alongside people I admire, is incredible.

If you're starting out or thinking about joining an early-stage startup, expect chaos, frustration, and plenty of unglamorous work. On the other hand, you'll learn more in one year than you would in five somewhere else.