There is no perfect technology — only decisions with better understood trade-offs.

The world of technology is constantly evolving. It’s fascinating to think that computers like ENIAC and UNIVAC were once reserved for a very select audience, while today it’s common to have a computer at home, see someone working on a laptop in a café, or communicate with someone thousands of kilometers away thanks to one of the most practical outcomes of nanotechnology: the mobile phone.

In a similar way, there is another field advancing just as rapidly to make all of this possible: software engineering. Having the best hardware means very little if the software cannot take full advantage of it. It would be like owning a car with a turbo V8 engine, but with tires that can’t go beyond 80 km/h. How could you ever make use of that engine?

In software, something new appears almost every day: a new framework, a new library, a workaround for a known bug, or even a new programming language.

With this constant stream of innovation, I’ve observed that development teams tend to fall into three categories when it comes to adopting new technologies:

• Teams that adopt new technologies as soon as they discover them, without evaluating how their product will be affected in the long term.

• Teams that take the time to analyze, test, and validate whether a technology will truly add value and scalability.

• Teams that resist change, whether due to fear, legacy constraints, or the learning curve involved.

My focus is on the first group: those who introduce new technologies without considering how their product will scale over time.

Projecting a product 10 or 20 years into the future is not easy. Most products evolve significantly in their early years due to changing user needs and competition. So the question becomes: how can we ensure that a product will scale over time with the technologies we choose?

There isn’t a single answer, but one interesting case is Xamarin.Forms. In its early days, it promised something close to the “holy grail”: write once, run anywhere. The developer community quickly became excited. However, over time, issues began to surface: redundant rendering, weak performance on Android, and significant overengineering even for simple tasks like customizing a button. Xamarin.Forms did achieve part of its promise, but complexity grew progressively.

Many teams that had invested in Xamarin.Forms eventually migrated to other technologies, spending time rewriting their codebases. Microsoft later introduced major changes, evolving it into .NET MAUI, but the migration process itself was complex. In many cases, teams chose to rebuild their applications from scratch, sometimes using frameworks like Flutter.

All of this happened in roughly 8 years — from its release in 2014 to its transition into MAUI in 2022. Now imagine your system, serving over 29,000 users, facing something like this precisely when you need to focus on competing — because others already have features your system still lacks, and you know implementing those requirements will be costly in a technology you may soon have to leave behind.

So what is the point of this story? It’s not about discrediting any company or technology, but about revisiting the original question: how do we make better long-term technology decisions?

Some considerations:

• Review the history of bugs and fixes in the repository.

• Evaluate community support and adoption.

• Consider how long the technology has been in the market.

• Check its compatibility with your team’s or company’s stack.

Among these, one factor often stands out: observing how the company behind the technology actually uses it.

It’s a simple idea: would you trust a doctor who recommends something they don’t follow themselves?

In the case of Xamarin.Forms, Microsoft promoted it, yet very few of their own applications were built with it. In hindsight, that’s a red flag.

On the other hand, technologies like React and Flutter have grown significantly, partly because the companies behind them use them in real, large-scale products. This isn’t about blindly following what Silicon Valley does, but about understanding how these technologies evolve and scale over time.

Choosing a technology is not just about solving an immediate problem — it’s about understanding the bigger picture. Just as you wouldn’t use the wrong tool to drive a nail, you shouldn’t choose the wrong technology to build a system.

Today, with AI tools like Claude, it is possible to generate applications in days instead of weeks. This introduces a new layer to the problem: we can now solve immediate needs quickly, without fully evaluating the long-term implications of those decisions — whether the modules follow clean and scalable architecture principles, or whether we truly understand the stack being used.

This is why teams with experience across multiple technologies tend to make better decisions. They are not limited to what they already know, but can evaluate different options and choose what works best both in the short and long term.

Complexity in systems will always grow over time: new modules, new requirements, new scenarios. The difference lies in ensuring that this complexity does not become a disadvantage due to poor initial technology choices.

Complexity will always grow. The real decision is whether the technology you choose will grow with you… or against you.