Twenty years in software is a long time, but not enough to stop being surprised. After two decades designing systems, writing code, and watching technical decisions become success stories or painful lessons, I have come to a conclusion that may sound like a cliché: technology advances, but the fundamental problems remain the same. What still amazes me is not a new framework or a disruptive paradigm, but how people, processes, and organizations interact with software. In this article I want to share some personal reflections, drawn from experience in complex projects, and how at Q2BSTUDIO we apply these lessons to create truly useful solutions.
When I started, I thought the success of a project depended almost exclusively on code quality. Over time I understood that software is, above all, a reflection of human dynamics. I have seen brilliant teams develop flawless architectures that failed because users did not adopt them, or because business areas interpreted the same data in contradictory ways. For example, in a recent financial systems integration project, the technical part was simple: connect APIs and synchronize databases. The complex part was aligning the expectations of accounting, treasury, and compliance departments. Each had its own definition of 'daily report' and its own deadlines. In the end, the solution was not more technology but facilitation work and process design, which we then materialized in a custom software application that adapted specific workflows for each area. That taught me that software architecture is also organizational architecture.
Another aspect that still surprises me is the fascination with complexity. In my early years, I fell into the temptation of using the latest technology just because it was new. I recall a project where we were evaluating whether to migrate to microservices for a medium-sized e-commerce platform. We spent weeks designing containers, Kubernetes orchestration, message queues... until a more senior colleague asked: 'What problem are we trying to solve?' It turned out the bottleneck was a poorly optimized SQL query and inefficient caching. We rewrote that query, added a couple of indexes, and performance improved by 500%. The lesson: often the simplest solution is the most effective. At Q2BSTUDIO we promote a pragmatic approach: before adding complexity, we ask whether we can solve it with what we already have. This does not mean rejecting new technologies, but using them wisely. For example, we have adopted AI agents to automate repetitive tasks in data processes, but always after validating that the problem cannot be solved with simpler logic.
Technical debt is another topic that, after twenty years, still gives me chills. We have all heard 'let's do it quickly and fix it later.' But that 'later' almost never comes. I have seen systems collapse because of a temporary decision that became permanent: a table without indexes, an insecure library that was not updated, a script that slept 360 seconds and when data volume grew caused crashes. On one occasion, a client company accumulated technical debt for years in its reporting system. The PostgreSQL database grew uncontrollably because maintenance tasks (VACUUM, analyze) had been disabled 'to save resources.' One day the disk filled up and the system stopped working for eight hours. The financial loss was considerable. Since then, at Q2BSTUDIO we place great importance on cybersecurity and proactive maintenance. We not only implement cloud solutions on AWS and Azure with auto-scaling, but also establish periodic review processes for technical debt, both at the code and infrastructure levels. Prevention is always more cost-effective than correction.
I am also amazed at how architectural decisions that seem right at one moment can become obsolete. Fifteen years ago, I designed a monolithic system for a logistics company. At the time it was perfect: fast, efficient, with a simple data model. Over time, the business grew, new sales channels emerged, and the need to integrate external systems appeared. The monolith became rigid, and any change required weeks of testing. I learned that architecture must be flexible, not perfect. Today, at Q2BSTUDIO we design systems with an evolutionary approach: we start with what works and iterate. We use patterns like event-sourcing or CQRS only when they make sense, always maintaining the ability to revert or modify. Artificial intelligence and data analysis also play a key role: we implement BI dashboards (Power BI) to monitor application performance in real time, enabling us to detect bottlenecks before they become serious problems.
Finally, I want to highlight the role of multidisciplinary teams. In twenty years, I have seen that the best projects are not those with the best programmers, but those that integrate business, design, operations, and security profiles from the start. At Q2BSTUDIO we foster that culture: our developers work side by side with business consultants and cloud experts to ensure that every functionality responds to a real need. In addition, we are exploring the use of AI agents to assist in code generation and testing, speeding up development without sacrificing quality. Technology continues to surprise me, but what I value most is the ability to learn from every project, every mistake, and every success. Twenty years later, I still believe that software is one of the most powerful tools for transforming businesses, as long as we use it with humility and a focus on people.
If there is one thing I have learned, it is that the greatest risk is not making mistakes, but not wanting to learn. That is why, in every new project, every complex integration, every cloud migration, I keep my eyes wide open to what experience continues to teach me: well-applied simplicity, team communication, and a holistic business vision are the pillars of software that truly adds value. And that, after two decades, remains a gratifying surprise.
