Context
I was a founding engineer for a startup, building B2C apps. We sunsetted the projects we had because they were not profitable, and the runway was over.
During my time in the startup, I led a small team and translated the business vision into actual products.
Let me share the main mistakes we made while trying to find product-market fit (PMF) in our products. This will be useful for solo founders and other CEOs/CTOs reading this blog. I hope you don’t make these mistakes:
1. Jack of all trades, master of none
Imagine you’re building an application that combines Twitter, and Habitica. Let’s call it “Habits”. You have social feeds, user profiles, followers, privacy settings, and users can track habits, send messages, and share photos. The first thing every single user is going to ask is: “What is this application for?” Each feature could’ve been a different app…
My advice is to stick to a single idea and solve an existing problem, even if it’s niche. Founders create and make up problems; most of the time, they’re only anxious.
Great founders should focus on solving existing problems, not creating new ones.
2. Wrong pivots
Remember the Habits app from the first point? Well, it was a public application using the B2C business model. The idea failed because there was no profit, even if users were still sharing posts and interacting in the app.
We pivoted, selling the same Habits app to organizations, allowing users to register with QR codes this time to increase retention rates. We put it in front of 10k users, and we only got 30 sign-ups in 2 weeks...
I learned the most valuable lesson with pivots: you cannot use the same method and expect different results.
3. It's just a small feature
I remember the first time I had to build chat rooms with the Habits product. It went okay, and it was a great learning experience. Later, I was asked to allow users to share habits with others via DM.
Suddenly, we were building 40 React components, fighting with responsive design, extending the core API, and creating multiple user stories in Excalidraw with the team, only to share a list...
Days later, we found out no one was using this feature, wasting 17 days of engineering and months of planning.
My suggestion is the following: add the features the user requests and what the business needs; don’t build without studying your users and metrics.
4. Marketing before product-market fit
Don’t hire a marketing team until you have achieved at least 1 paying customer.
Marketing amplifies your value. If your value is 1, you’ll still get 1; if your value is 3, you’ll have 9.
5. Notes for developers
Use Terraform or Pulumi to define your infrastructure; clients need the architecture to be replicable.
Create runbooks. Document how database migrations run, how to set up the development environment, and how common product operations run.
Don't separate frontend from backend in an MVP. Don't do microservices.
Write tests and keep the product documented. This way, you can make changes to the code without worrying about it breaking.
Don’t fly blind in production. You need analytics, metrics, logging, and monitoring even for a single VPS.
Learn outside of work. Learn what you’re passionate about, contribute to open source, or build projects outside work.
Embrace AI and agentic workflows. You’ll still have to review the AI’s code and ensure you’re shipping the right thing to production.
Conclusion
Startups are hard, and most of the time, as an engineer, you cannot determine whether the product will be successful or if it's another lesson to learn from.
That's it. Those are the mistakes. Thanks for reading!
I'm building again. Available for Open Source collaborations, building Saas Products, and helping companies scale their products: https://www.itsfranciscoluna.com/
Top comments (0)