From Rome to MIT: What Moving Between 3 Countries Taught Me About Building Products

When I left for university, I didn't know I was starting a pattern that would define everything I built.

Rome first, aerospace engineering at La Sapienza, one of the oldest universities in the world. Then MIT in Boston for research. Then flight schools across Belgium. Then Tijuana, Mexico. Then San Diego. Then back to Milan.

Each move changed what I assumed was normal. And assumptions are the invisible architecture behind every product decision.

Rome: Learning to Build With Constraints

La Sapienza doesn't give you resources. It gives you problems.

The aerospace engineering program was rigorous, theoretical, and underfunded. Labs had equipment from the 1990s. Computing resources were limited. Research budgets were tight. You learned to do more with less, not as a philosophy, but as a survival skill.

This shaped how I build software. I don't reach for expensive infrastructure first. I don't assume unlimited compute. I build products that work on modest hardware, with modest bandwidth, for users who don't have the latest iPhone.

Aviation Infinity's first version ran on a $5/month server. It served thousands of students before I upgraded the infrastructure. That frugality came directly from an Italian engineering education that taught you to solve problems with what you have, not what you wish you had.

Italian engineering culture also taught me something about aesthetics. In Italy, ugly things are personally offensive. A bridge isn't just structural. It's beautiful. A car isn't just functional. It's designed. This cultural reflex made me incapable of shipping truly ugly interfaces. Even my hackathon projects had better design than they deserved, because I couldn't bring myself to demo something that looked bad.

MIT: Learning to Think in Systems

MIT was a different universe.

The resources were staggering: labs, equipment, funding, talent. But what changed me wasn't the resources. It was the way people thought.

At La Sapienza, I learned to solve specific problems. At MIT, I learned to think in systems. Not "how do I calculate this aerodynamic coefficient?" but "what's the system architecture that produces reliable aerodynamic calculations across all flight regimes?"

The shift from "solve this problem" to "build a system that solves this class of problems" is the foundation of everything I've built since. Aviation Infinity isn't a question bank. It's a learning system. ClickAi isn't a website template. It's a generation system. LegalAgento isn't a lawyer directory. It's a matching system.

MIT also taught me about intellectual ambition. In Rome, ambition meant getting a good grade. At MIT, ambition meant changing the field. People around me were building spacecraft propulsion systems, autonomous vehicles, and computational fluid dynamics models that would take a decade to validate.

That scale of ambition (thinking in decades, not semesters) stuck with me. Aviation Infinity is eleven years old. ClickAi is seven years old. I'm not interested in building things that last a year.

Belgium: Learning to Fly (Literally)

Flight school was the most humbling experience of my life.

I went from an academic environment where my brain was my primary tool to a cockpit where my brain could kill me. Aviation training teaches you that intelligence without discipline is dangerous. You can understand stall aerodynamics perfectly and still stall an airplane if you're not following the checklist.

The flight training environment in Belgium was multinational, with students from across Europe, the Middle East, and Africa, all studying together. Communication happened in English, but the cultural subtexts were in a dozen different languages. I learned to communicate across cultures not in a business school seminar, but at 5,000 feet with a Belgian instructor who expected French precision and an Indian classmate who communicated in British-English understatement.

Flight school also taught me about checklists. Not the productivity-guru kind of checklists. Real checklists, the kind where skipping a step means the landing gear doesn't deploy.

Every product I build has checklists built into the operational processes. Deployment checklists. Launch checklists. Content review checklists. Not because I'm compulsive, but because I've experienced firsthand what happens when you trust memory over process in high-stakes environments.

Mexico: Learning That Everything You Assumed Is Wrong

Moving to Tijuana broke every assumption I had about how technology products should work.

In Rome and Boston, I'd built products for users who had broadband internet, modern devices, and credit cards. In Tijuana, I built Comensalaqui (a food delivery marketplace) for users who had spotty mobile data, older Android phones, and preferred to pay in cash.

Every "best practice" I'd learned was wrong:

• "Optimize for the latest browsers": my users were on Android 5, three versions behind.
• "Use responsive web design": my users needed a mobile app because their browser experience was too slow.
• "Accept credit cards": my users didn't have credit cards. Cash on delivery was the standard.
• "Minimize user input": my users wanted to negotiate, customize, and communicate before committing.

Tijuana taught me that product-market fit isn't universal. A product that's perfectly fitted for San Francisco can be completely useless twenty miles south. The border between the US and Mexico is twenty minutes of driving and a century of infrastructural difference.

This lesson saved me later. When Aviation Infinity expanded to Africa and Southeast Asia, I already knew not to assume broadband, modern devices, or Western payment methods. The product worked because I'd already learned that my assumptions were provincial.

San Diego: Learning to Ship

After Mexico, I moved to San Diego and entered the American startup ecosystem.

The pace was different. In Italy, you plan for months before building. At MIT, you research for years before publishing. In San Diego, you ship on Friday and iterate on Monday.

I joined Brojure as CTO, built BorderBot as a side project, and started competing in hackathons. The cultural expectation was clear: stop planning, start shipping.

This was liberating. I'd spent years in environments that valued rigor over speed. San Diego's startup culture valued speed over rigor. The truth, as always, is somewhere in between, but I needed the American bias toward action to balance the European bias toward planning.

ClickAi was born from this mindset. I didn't plan ClickAi for six months. I built the first version in weeks and put it in front of users. The feedback was immediate. The iteration was fast. The product improved more in three months of shipping than it would have in a year of planning.

Milan: Bringing It All Together

I eventually came back to Milan, and everything clicked.

Italian aesthetics. MIT systems thinking. Belgian discipline. Mexican empathy for constrained users. American shipping speed.

Each environment contributed a skill that the others lacked:

• Rome: Build beautifully with constraints.
• MIT: Think in systems, not features.
• Belgium: Follow the checklist. Every time.
• Mexico: Never assume your user's infrastructure.
• San Diego: Ship now, improve tomorrow.

The Agento suite (six AI products launched in parallel) is the product of all five environments. Each product is built frugally (Rome), architected as a system (MIT), operationally disciplined (Belgium), globally aware (Mexico), and shipped fast (San Diego).

No single environment could have produced this. The combination is the point.

The Lesson for Builders

You don't need to move to five countries. But you do need to break your assumptions.

Every environment you've worked in has given you a set of invisible beliefs about what's "normal." Normal internet speed. Normal device quality. Normal user patience. Normal payment methods. Normal expectations.

Those beliefs are true, in your environment. They're not universal.

The fastest way to break them is to build for someone who doesn't share your assumptions. Build for a user in a different country. Build for a user with a disability. Build for a user who's thirty years older than you. Build for a user who's never used a computer before.

Every assumption you break makes your products more resilient, more accessible, and more useful to more people.

I broke my assumptions by moving. You can break yours by choosing to build for users who aren't like you.