.svg)
.png)
Tiago Franco, founder and chief executive of Imaginary Cloud, faced a problem that eventually confronts every technology company. The expertise that had made his company successful was losing track. Not because the technology itself had lost technical maturity or robustness, but because its market relevance had declined as the industry moved towards a different tech stack.
For the first few years, Imaginary Cloud delivered projects primarily in Ruby on Rails. Then prospects began rejecting proposals with increasing frequency, largely due to the technology stack. The reason was simple: React and Node.js were the new hot thing.
What makes Franco's experience worth examining is not that he successfully navigated this transition. What makes it valuable is not failure, but the fact that the transition was unstructured, difficult, and costly before a systematic approach emerged that could be applied to future technology shifts. This is an account of that journey and the lessons it revealed.
This interview is part of our Strategy Pattern series, exploring how organisations adapt to change. You can read more and see other interviews in the series here.
Franco founded Imaginary Cloud, a digital transformation consultancy based in Portugal that helps clients deliver and be present in the digital space. Since its founding in May 2010, the company has helped scale over 300 digital products across Europe, the United States, and the Middle East, serving clients such as Nokia, BNP Paribas, and Thermo Fisher. The company now employs over 100 professionals across four offices worldwide and maintains a 99% client recommendation rate.
He built Imaginary Cloud after working as a software engineer and project manager for organisations including CERN, the European Space Agency, and the UK Ministry of Defence. What characterised these organisations was their deep reliance on innovation and research and development, a mindset Franco carried into Imaginary Cloud.
However, that focus was largely driven from an engineering perspective rather than from the user’s goals, a tension that shaped his belief that the development process needed to change.
The founding thesis addressed what Franco saw as a recurring problem: quality-centric software is often challenging to use and prone to human error because it doesn't focus on the user. That way, he believes many companies prioritise user experience but compromise on quality." Imaginary Cloud would merge both approaches.
Ruby on Rails became the primary technology because it aligned with this vision. For the first few years, the strategy worked and the firm delivered dozens of projects across the world. Then the market shifted, influenced in part by Facebook’s decision to open-source React and promote new architectural approaches that favoured JavaScript-based stacks such as React and Node.js over more traditional frameworks. Today, companies face a similar challenge with AI technologies, where rapid adoption pressures can make established tools or processes feel obsolete.
The shift happened faster than Franco anticipated. React and Node.js, which represent a fundamental architectural shift from monolithic to microservice patterns, became what Franco describes as "the one that every client wanted to start with." Ruby on Rails "stopped being a desirable technology to start a new project."
The paradox was critical. Imaginary Cloud was proposing Ruby on Rails solutions that were technically superior for the early-stage products most clients were building, and 30 to 40% less expensive than microservices alternatives. Yet clients rejected these proposals solely because of the technology stack.
"The client was not getting more value. The client was getting less value because they were paying more for a technology that is less suitable for the stage where they are, but they were simply not buying that tech stack."
Franco decided to transition the entire company to React and Node.js. But he had no systematic approach for executing this transformation. The result was what he now characterises as profound inefficiency.
When asked how he framed the problem and communicated the transition strategy to the company, Franco's response is direct: "I didn't. That's the point. This is what has changed in me as a leader through the years. In the early stages, I didn't know how to deal with this change."
Instead of a structured plan, Franco took immediate action. "We just started delivering proposals in React. We started delivering projects in Node and React, and it was all very action-oriented." Some clients accepted these proposals at higher prices, which required more man-hours than with Ruby on Rails. Projects began, but problems quickly emerged: the stack was new, and these were the company’s first projects using it.
Resistance was predictable but unprepared for. Engineers who had mastered Ruby on Rails saw colleagues exploring other directions. "It is natural for people to experiment with new technologies, and that can be healthy," Franco explains. "But it is the organisation that must decide what to adopt. Some engineers explored React or other tools like Elixir."
"We just started doing stuff, and some people showed resistance. We ended up using them in Node.js projects, some of which were adapted. I would say the majority did after some time. But I didn't communicate a strategic direction, saying this is where we need to go. It was more like we started doing stuff. That was inefficient."
Some engineers left the organisation, but not because they were experimenting. They left because they loved Ruby on Rails and did not want to deliver projects in a different technology, while the market for Rails was shrinking. As Franco notes, "When an organisation changes, some people adapt with it, and some do not. This lesson applies to any transition."
The breakthrough came from recognising a pattern Franco had encountered repeatedly.
As he explains:
"What usually takes you there doesn't take you to the next step. So the environment changed, and you need to change with it."
This happens, Franco notes, "very often. It usually happens every few years where you need to adapt the way you are delivering software just because the environment changes."
Franco also recalls advice from a university professor who told a fellow chief executive:
"The strategic plan needs to change as little as possible, and as often as necessary."
The paradox captured what Franco was learning: strategy requires commitment over three to five year horizons, but rigid adherence to failing strategies guarantees obsolescence.
"The techniques that I apply now to deal with that change are completely different. They're more mature than they were in the early stages." The difference came from learning through experience and also seeking formal training in corporate strategy, which allowed him to approach transitions with a systematic, rather than improvised, framework.
What emerged from multiple transitions, Franco's first was chaotic, his second marginally better, his third more systematic, was what he now identifies as a repeatable pattern.
The Strategy Pattern, originating in software engineering, defines a family of algorithms, encapsulates each one, and makes them interchangeable, allowing algorithms to vary independently of the code that uses them.
It is a behavioural pattern designed to provide flexibility and avoid hard‑coding behaviour. For example, you might have a function like calculate_time_home(strategy), where the strategy could be the fastest route, a scenic walk, or another approach.
Just as software can swap algorithms at runtime when implemented using the Strategy Pattern, a company should not be locked into rigid, outdated practices. Organisations can change processes or technology stacks without rewriting the entire system, making them more flexible and maintainable rather than brittle and obsolete.
When asked to describe what other leaders should do when facing similar transitions, Franco's response reveals the core of the pattern: "The first thing that they need to do is to decide what that change is, which direction they are going. And after that is decided, then you need to stop doing whatever needs to stop, and you need to start doing whatever needs to be started to get to that goal."
But before any of that, Franco emphasises:
"Before you understand what you need to stop doing, you need to understand where you're going. Do a diagnostic of where they are now and where the industry is going, and then define a strategy."
This framework operates across three integrated dimensions that Franco learned must be addressed simultaneously.
Franco's first lesson was distinguishing structural market shifts from temporary fluctuations. Ruby on Rails did not disappear. It simply ceased being the default choice for new projects. That distinction mattered.
During the Ruby-to-React transition, the diagnostic revealed an uncomfortable truth. Clients were demanding technology that delivered less value at a higher cost. But the demand was consistent across markets and sustained over time. This indicated a structural shift, not a temporary trend.
Franco's mature approach, developed after the initial failure, involves explicit strategic planning: "We drive a strategy and design a strategy for three years. This is what we want to achieve."
But the plan must be communicated with absolute clarity:
"You do the diagnostic, you prepare the strategy, and then you make sure that the strategy can be presented to everyone on one page. And then you share that strategy with everyone."
The technical dimension addresses reality Franco learned through experience: transitions cannot happen instantaneously. Imaginary Cloud did not abandon Ruby on Rails entirely. Existing client projects continued in their original technology. New projects launched in React and Node.js.
The solution Franco developed was creating communities of practice.
"We ended up creating what we call communities of practice, where people could share knowledge on technology that they use."
These communities served multiple functions: accelerating knowledge transfer, creating social proof through visible success cases, and establishing standards without central bottlenecks.
Franco also had to restructure teams. "We had to separate front-end from back-end specialisation because of the market forces that. Before, we didn't have that. It was just full-stack." This separation created new coordination challenges that communities of practice helped address.
The cultural dimension proved the most complex. Franco explains that people respond differently to change.
Some embrace the new technology immediately and become early adopters. Others resist at first, but once they see colleagues achieving results and the benefits of adoption, they gradually follow suit. Finally, some choose not to adapt and may leave the organisation if the change conflicts with their preferences or principles. "When an organisation changes, some people adapt with it, and some do not. Understanding this dynamic is critical, and it is a lesson that applies to any transition," Franco notes.
Franco's framework recognises three populations. Early adopters embrace change enthusiastically. Pragmatists adapt when evidence of success becomes clear. Resisters prefer the old approach and view the transition as unnecessary or misguided.
"Leadership deals with change. Leadership sets direction and ensures change happens. Change is messy. When change is happening, sometimes we don't know if you are right or if you are wrong, but we need to go in that specific direction."
The validation of Franco's pattern comes from measurable results. Imaginary Cloud maintained its 99% client recommendation rate throughout the transition, despite the learning curve and higher project costs during the 18-month transformation period.
More significantly, the pattern proved transferable. Franco has applied the same framework to subsequent transitions, including cloud native architectures, serverless computing, and artificial intelligence integration. Each transition went more smoothly because the systematic approach replaced improvisation.
Three categories of activity emerge once direction is established.
Investment in capabilities that contradicts strategic direction. Marketing services the market no longer values. Active resistance that undermines strategic initiatives. As Franco explains: "If you change strategy, if you change direction, the strategy will tell you what you need to stop doing."
Building strategic capability despite immediate cost. Measuring transition progress with specific metrics. Communicating strategic rationale repeatedly until the message becomes embedded in organisational consciousness.
Existing client commitments. Quality standards despite efficiency pressures. Market positioning whilst changing only the technological implementation.
Franco emphasises that successful transitions preserve more than they discard. During the Ruby to React transition, Imaginary Cloud's operational model, client relationships, and market positioning remained constant. Only the technological implementation changed. This prevented attempting simultaneous transformation across multiple dimensions.
- Interchangeable solutions: The same framework applies whether you are shifting tech stacks, adopting AI, or restructuring teams. The decision logic remains constant, even as specific challenges change.
- Context-independent logic: The decision sequence applies to startups and enterprises, though execution varies. A 20-person company and a 2,000-person organisation face different implementation challenges but follow the same strategic pattern.
- Maintainable at scale: As Franco learned, having a clear pattern prevents the chaos of ad-hoc change management. "This happens very often," he notes. "It usually happens every few years, where you need to adapt the way you are delivering software just because the environment changes."
Other leaders can adopt Franco's approach not because they face the same technological challenge, but because they encounter the same pattern of environmental change requiring strategic adaptation. The tools change, but the decision framework remains robust.
Franco's journey from Ruby on Rails to React is already outdated, but it was one of the first challenges he had to endure. However, his framework for navigating change remains relevant because it is a Strategy Pattern: context-independent decision logic that adapts to any challenge.
The lesson is not "adopt microservices" or any specific technology. The lesson is to systematically monitor for shifts, whether in AI, software frameworks, or business models, diagnose before acting, test before committing, and communicate honestly.
This pattern works whether you are a 50-person software company or a 5,000-person enterprise, whether you are changing technology stacks or business models, and whether your "Ruby on Rails moment" occurs next quarter or in five years.
The only certainty is that your moment will come: proposals will be rejected, core competencies will become obsolete, and the environment will shift. At that point, you must choose to adapt intentionally or risk being left behind.
If you would like to discuss how this framework can be applied to your organisation's technology transformation, platform migration, or strategic technology decisions, please contact our team.
Alexandra Mendes ist Senior Growth Specialist bei Imaginary Cloud und verfügt über mehr als 3 Jahre Erfahrung in der Erstellung von Texten über Softwareentwicklung, KI und digitale Transformation. Nach Abschluss eines Frontend-Entwicklungskurses erwarb Alexandra einige praktische Programmierkenntnisse und arbeitet nun eng mit technischen Teams zusammen. Alexandra ist begeistert davon, wie neue Technologien Wirtschaft und Gesellschaft prägen. Sie liebt es, komplexe Themen in klare, hilfreiche Inhalte für Entscheidungsträger umzuwandeln.
CEO von Imaginary Cloud und Mitautor des Buches Product Design Process. Ich mag Essen, Wein und Krav Maga (nicht unbedingt in dieser Reihenfolge).
People who read this post, also found these interesting:
