Working at a unicorn startup was an experience that profoundly improved my perspective on software engineering. Not just because of the product’s scalability or the company’s accelerated growth, but mainly because of the real problems that arise when software ceases to be “just code” and becomes a critical part of a business experiencing exponential global growth.
I joined at a time when the company was already dealing with millions of users, expanding engineering teams, and constant pressure to deliver quickly—without breaking what was already working.
Below are some of the most important lessons I take away from this experience.
1. Scale doesn’t just break systems — it breaks naive decisions.
Before working in a large-scale environment, it’s easy to believe that “we’ll deal with it later” or that certain technical decisions are irrelevant in the short term.
In practice, I learned that:
-
Small decisions add up quickly.
-
“Temporary” solutions almost always become permanent.
-
Premature optimizations are bad, but ignored technical debt is worse.
I’ve seen systems suffer not from a lack of technology, but from a lack of clarity about trade-offs. At various points, the decision wasn’t between “right or wrong,” but between:
-
speed vs. maintenance
-
cost vs. performance
-
simplicity and flexibility
I learned to justify technical decisions more clearly, thinking about the future impact — not just on the code, but on the team.
2. Engineering is communication before it is code.
In a large team, writing code is only part of the job.
Many of the most difficult problems were not in the implementation, but in:
-
align expectations with the product.
-
Explain technical risks to non-technical people.
-
Negotiate deadlines without compromising quality.
-
Documenting decisions for teams that didn’t even exist yet.
I learned that an effective engineer isn’t the one who writes the most complex code, but the one who reduces uncertainty for the team.
This changed my approach to:
-
write RFCs
-
participate in reviews
-
to argue about architecture
-
dealing with feedback and disagreements
3. Mistakes happen — what matters is what the team learns from them.
Incidents, production bugs, and decisions that didn’t work out were part of the routine. The difference lay in how the team reacted to them.
The environment taught me to:
-
Treat failures as learning opportunities, not as reasons for blame.
-
to value well-done post-mortems.
-
Improve processes, not just fix symptoms.
-
to create more observable and resilient systems.
These experiences have made me more careful when making changes in production and more aware that reliability is a feature.
4. Growth requires letting go of technicalities.
One of the hardest lessons was accepting that:
-
Not all code needs to be “elegant”.
-
Not every solution will be rewritten in the ideal way.
-
The business context matters as much as the technique.
At various times, the best decision wasn’t the prettiest one, but the one that allowed the team to move forward safely. This taught me to balance technical perfectionism with pragmatism.
Conclusion
Working at Brazil’s first unicorn taught me that software engineering at scale is, above all, about people, decisions, and impact.
I emerged from that experience as a more mature engineer, more aware of the trade-offs, and better prepared to handle complex systems and teams—whether in small startups or large-scale companies.
These are lessons I carry with me into any future challenge.