Highly Opinionated Disclaimer: This post is a personal reflection based on my last six years in the field. It is not a technical manual or an absolute truth, but rather a synthesis of the observations I’ve gathered “on the ground” as a Staff Engineer and aspiring Architect.
After six years of building AI systems for both US-based companies and Brazilian organizations, I’ve realized that your choice of architecture isn’t just dictated by your data or your stack—it’s dictated by the context in which it lives.
Working across borders has revealed distinct patterns. On one side, a focus on absolute rigor and metrification; on the other, a focus on pragmatic survival and immediate ROI. Here are my notes on how these different environments shape our technical decisions.
1. The “Build vs. Buy” Paradox
In many US-based companies, “Buy” is the default. You purchase a managed vector database, a specialized monitoring tool, and a premium support tier. The goal is risk mitigation: you want an official SLA and a direct line to the vendor when things break.
In Brazil, import taxes and currency fluctuations often turn “Buy” into a prohibitive luxury. This has forced us to become highly proficient at internalizing Open Source.
- The Observation: We don’t just use tools; we often fork and maintain them.
- The Architect’s Lesson: In critical moments, having an in-house specialist who understands the code “under the hood” can be more valuable than waiting for an account representative in a different time zone.
2. The Hidden Tax of Language and Data
Engineers in English-centric markets often take data for granted. In English, datasets are a commodity. In Portuguese, they are a treasure hunt.
I once worked on a project where we had to hire a voice actor to read an entire book just to create a high-quality speech dataset. This “data debt” means that a system hitting 90% accuracy in a US benchmark means very little for the Brazilian market if it isn’t properly localized.
- Technical Constraint: Language is an architectural variable. When documentation is misunderstood or translation fails, the risk of “infrastructure failure due to misinterpretation” becomes a real vulnerability.
3. Pragmatic Engineering: Resourcefulness vs. Rigor
One thing needs to be clear: Brazil has incredibly resourceful and capable professionals. Frequently, we create cutting-edge solutions that compete with—and even outperform—architectures built with unlimited budgets abroad.
While US companies are often obsessed with measuring everything—from DevEx to maintainability—with surgical precision, the Brazilian market often focuses on the “worth it” factor in the short term.
- The Balance: This can lead to improvisation, which creates technical debt. However, it also fosters an agility that ultra-specialized, siloed teams rarely achieve. My goal as an Architect is to bridge these worlds: applying rigor where it protects the business without stifling the creative problem-solving that scarcity demands.
4. ROI from Day 1 and Accountability
In the US, AI can often be a long-term experiment. In Brazil, it must pay for itself—often immediately.
I’ve seen R&D teams in Brazil acting as internal consultants or securing innovation grants just to keep a product’s runway alive. This pressure creates a deep sense of Accountability. We don’t build models because they are trendy; we build them because they need to bring value to the table today.
Conclusion: From Implementation to Architecture
Working across these two worlds has taught me that a great architect isn’t someone who always chooses the most elegant or the “correct” textbook solution. A great architect is someone who understands the context.
Sometimes, the right solution is a $50k managed service. Other times, it’s a custom-built fork that your team understands deeply and costs a fraction of the price. I’m building systems that don’t just work—they respect the reality of the market they live in.