Introduction
Most people think I'm stubborn about startups, products and the standards I developed are insane.
Maybe they are. But when you've faced user complaints directly, you have to manage a database at 12pm on a Saturday because of broken SQL scripts, phantom docker containers, extreme technical debt, talking with the CEO directly and falling for scope creep, you already know I had to learn how this game worked.
Let's mention the 7 most important points and lessons I learned while being a founding engineer from a third world country, Venezuela.
1. Scope Creep
I've seen this a lot. Adding features because they're cool or "just in case". When you're a founding engineer, there's a skill you must develop. Negotiating scope. Because the CEO and the non-technical part of your team want to add features all the time.
I'm skeptical about scope nowadays. Because I was responsible of building products no one understood and I was saying yes to every single one of the CEO's ideas.
My advice? Please, keep scope simple for MVP and introduce the core features. Iterate as you go and always validate your feedback with other users and the competition.
Always prefer a tough discussion that'll save the project over sweet acceptance.
2. Poor Software Architecture
Let's be honest. Proper software architecture is not overengineering. It's about using the 20% of techniques and patterns that will give your codebase of results. This is called the Pareto principle.
For a MVP you don't need:
- Utility classes
- Complex mappers
- Aggregators
But:
- DTOs
- Repositories
- Entities
- Handlers
- Use cases
The core goal of software architecture is to make the software flexible and to iterate faster through decoupling. It's a simple concept: Your code should not be glued together like a wall, but rather it's a set of flexible Lego blocks you can work with.
Because if your stakeholders ask you for a change of the requirements (spoiler: they will) or if you need to fix a bug you, you're not spending 5 hours going through spaghetti code but 30 minutes tweaking a use case, making things easier to test and deploy.
3. Complexity
One day some guys on LinkedIn were talking to me about their architecture. They were telling me they were using microservices. I asked them about their DAU rate. It was less than 100.
In that moment, I wanted to turn off the computer just to process this.
The problem is not microservices themselves. They're a tool to be used once your company and products scale and you need to separate responsibilities. But are you aware of the maintenance overhead you're introducing with this choice?
Choose a proper modular monolith when you're getting started, collect metrics, talk to users and iterate your business idea as you go.
The simpler it's to get started and iterate, the more chances of winning you have. Because you have more room to test and experiment, and in the real world, users don't care about your API gateway, only if the feature works and if it's reliable enough.
4. Not everyone will get it
Sometimes, it's better to be alone with senior engineers, CEOs, CTOs and those who are with you in the trenches.
No. I'm not telling you to stop networking but to get your priorities right.
When you're building a complex multi tenancy architecture, writing tests to prevent lawsuits and stress testing the system you don't need to be with people who are asking you how the Python syntax works or how they can center a div.
The best choice you can make is to bet on yourself, your future, skills and the people who are with you in the trenches.
Mentor others and document, but value your time for deep work.
5. Testing DOES matter
I still remember the tragic day of launch where a major stakeholder found they could not use specific characters when trying to login into the system. We had little to no tests and we were assuming our input DTOs were working fine.
Spoiler, they were not. You don't need 100% test coverage, but always consider testing the following modules through both unit and integration tests:
- Auth
- Payments
- Input DTOs
- Permissions
- Access control systems
6. Academia might betray you
I'm not telling you to stop studying or learning, but the opposite, knowledge is power. However, you need to develop pragmatism and avoid falling for dogmatism (dogma).
Dogma is having the belief things should always be done in a specific way no matter the situation. Pragmatism, on the other hand, is knowing when to break a specific rule while considering the trade-offs.
Look, once I designed 35 tables using the 5 possible NFs of Database Design for MVP.
For what?
- 87 users in 2 months
- Complex queries with 3 joins
- Servers down
- User complaints
When I read Designing Data Intensive Applications and I learned it was fine to just have a JSONB row in my tables, it changed my life.
Because sometimes the only way to win and keep your sanity is to break the rules. Sadly, this is something you learn only through experience.
Which is why I'll still insist about avoiding dogma.
7. Life outside startups
I wish someone would've told me these things before. I learned these the hard way and I hope you can learn from them.
- Protect your relationships at all cost
- Learn how to read and understand legal contracts
- Learn about human psychology and power dynamics
- Learn how to say no
- Learn how to negotiate
- The startup is a medium, not the end
- Equity is NOT free. Make sure it aligns with your future plans
- Save yourself. Not a company. Not a startup. Your own self
Conclusion
As Ging Freecs says:
"You should enjoy the little detours to the fullest. Because that's where you'll find things more important than what you want."
Thank you for reading. Don't take this advice literally. This is only my philosophy about startups at 21.
Top comments (0)