What Building Startups Taught Me

The Motivation

Starting a company was always something that intrigued me, as I’m sure many of my fellow peers who grew up in the San Francisco Bay Area can say. After working as a software engineer for big tech for several years, I realized that I had the technical skills to ship software systems end-to-end in production. Although I didn’t fully understand the other skills that were required, I thought taking the leap was the best way to find out. It was mainly my curiosity that was the motivation to leap. To see how hard it would be to create something from scratch.

I’ve attempted about five ventures in the past 7 years, in a variety of domains (not ideal, as maybe sticking to a single domain would have served me better). The lessons below are an aggregate of those experiences.

The Early Days of a Project

Having an idea is exciting, and AI coding tools especially have made the early-stage execution incredibly quick to implement. I blast through the initial frontend, backend, and database creation with Claude Code. Fire up a new Git repo and push. Set up CI/CD and deploy everything to my favorite managed cloud infra. Buy a custom domain and hook it up, we’re live baby!

The adrenaline continues, as I expand the app with complex UI animations, a react-native webapp that deploys to iOS/Android in a single shot, and an LLM prompt-chain to effectively process any unstructured input. This couldn’t get any better, because I’m totally locked in.

Chatting with Customers

As an engineer in big tech, your work is always scoped to a very specific box, and you never needed to interact directly with the customer. However, when starting a company the customers are literally the main thing you’re supposed to focus on (nice to see Jeff Bezos’s Customer Obsession principle in full swing here). But how in the world were you supposed to find people to sell to? I researched all the usual venues: contacting people in my network, DMing folks on LinkedIn, and scouting leads at in-person events.

Damn this was turning into a real grind. I was spending most of my days following up on emails, booking calls, and convincing folks why my product was worth it.

The YC Video Rabbit Hole

I love the YC youtube channel, and all of their content was super helpful. A personal favorite of mine, How to Talk to Users. I think I’ve watched this video at least a dozen times. I realized I had it all backwards, and starting with the idea first is doomed to fail. The message repeated was to start with the problem and iterate on the solution until it works.

My conversations with potential customers changed. I stopped trying to push a product, and started asking questions to probe the problem space. This was the single biggest change in how I approached early users. I learned that there is no such thing as an easy domain: Every single domain and problem space is hard, and the problems you think your idea solves are most likely way damn harder than you think. Whether it’s hard-to-access data siloed inside proprietary companies, long sales cycles in regulated industries, or just reluctance of certain domains to accept new technologies, the problem space is always more brutal than expected.

Domain Expertise

As a software engineer, you can build tools for almost every single domain. The basic stuff that every industry uses (Email, Slack, Spreadsheets, WhatsApp, QuickBooks, Outlook etc.) are all software at the end of the day which can be hooked together and automated. However, when building a startup in a specific domain, you are essentially claiming you have a solution which is at least 10x better than the currently accepted industry practice. Clearing this bar takes intensely deep domain expertise, which only happens when you and your partners get and stay neck-deep in the domain.

Profitability

Getting people to give you money is damn hard. Let’s assume, however, that you manage to convince a few folks to pay you, incredible! However, true profitability from the SaaS route means you need to have many customers who subscribe to use the same software. The whole economic advantage of software is that the code is written once, and the marginal cost of reproducing it is zero. This implies that the problem you are solving is so predominant, and impacts so many people, that your software is essentially a one-size-fits-all solution. Clearly, creating this one-size-fits-all solution is not easy unless you are a master of the domain.

Falling Behind in your Craft

A personal issue I encountered, as I floated between different domains, was that I was focusing more of my time learning the intricacies of the domain instead of engineering. There was a real pain here, as I could literally feel my software skills atrophy as I stopped using them: Every day I spent doing cold-outreach and talking to customers was time I could feel the blazing pace of the software industry passing me by.

How were other technical founders making time for their craft? Maybe engineers should stick to building systems, and leave sales and distribution to the sales people? Was it possible to deeply care about your craft, but still build a company? It seemed like a tough problem, and it seemed like distribution was the key.

Distribution

If I as an engineer thought of myself as a cook, like Walter White, it made sense to me I might need a Salamanca to handle the distribution. However, as a founder in the real world, you might need to become a Salamanca yourself. When thinking about distribution, you have to ask the following questions about the folks in your domain:

• Where do they hang out?
• What content do they consume?
• Who do they trust?
• Who are the leading voices in their space?

Before a single line of code is written these questions ideally need to be answered. It is essential that the what you build to solve the problem, will be paired with how you will distribute it. It was a mistake I made not focusing on these questions early, leading to painfully slow distribution for a product I had already sunk time into.

The Abyss

After a while, it was painful to see all the things I needed to focus on, to get a functioning company off the ground:

• Profitability, with paying customers
• Distribution, with the associated sales and marketing
• Engineering, and building out a high quality product
• Domain Expertise, to become the master of the space you’re building in
• Problem Expertise, to understand the specific problem you’re solving inside and out

It was a monumental task, and many days felt too full. I kept reminding myself that I have the same number of hours in the day as the President, so clearly the task was to figure out how to spend these hours more effectively. I started asking hard questions like:

• Am I cut out to solve this problem?
• Do I love the problem?
• Do I even want to learn this domain?
• Can I see myself doing this for the next 5-10 years?
• What am I best at, and am I leveraging myself the best I can to get better at that?

It can lead to a pretty lonely place, especially when all your family and friends know that you are trying to focus on creating something from scratch.

Final Thoughts and Lessons

Entrepreneurship is painful, but incredibly exciting. It is a rollercoaster in the realest of senses, with extreme emotional ups and downs, and I learned there is a hell of a lot more than being a good engineer. As I continue down the path, I’ll be sure to integrate the lessons I learned along the way.

1. Choose a domain carefully.

Ask yourself what domain you have experience in, and if you can see yourself in it for the next 5-10 years. Committing to become a master is the only way, as you will need to understand the problem deeply enough to create a 10x better solution than the currently accepted industry solution.

2. Understand what distribution looks like

Know the people who will be your customers, and how you will reach them. Personally, I would have done more to utilize media (ex. writing and video) as it is another medium whose marginal cost of reproduction is zero.

3. Collaborate with other founders and get a mentor.

Making connections with folks in the same space as me, as well as talking to someone who had walked the path before would have saved so much time. Especially when early in the journey, the speed of learning is critical. The few experienced folks I talked to, always gave immensely helpful advice.

In my next venture, I’ll be factoring in these lessons and more: collaborating with more founders, getting a mentor, choosing a domain I can commit to master, and understanding what distribution looks like. The only thing I can guarantee is that new lessons will pop up, and I most definitely will be documenting all of them.