Innovation is a mindset, not a milestone
Embed technical agility into your engineering culture
As the CTO at Jimdo, I’ve often observed that application innovation is frequently discussed as a monolithic event: a digital transformation or a cloud migration, as if it were a one-time initiative that, once completed, allows the organization to shift its focus elsewhere. But in reality, application innovation isn't a project with a start and end date; it is an operating principle that must be embedded into your engineering culture.
The real challenge for any tech leader isn’t choosing between new features and maintenance. It’s the continuous management of engineering energy. Recently, when I sat down with Trey Guinn, field CTO at Cloudflare, on their show Beyond the App Stack, we discussed this exact tension: how to ensure agility doesn't sacrifice stability.
For me, the answer starts with alignment. I don't believe in consensus; it is too difficult to achieve in a growing company. Instead, I believe in a top-down strategy paired with bottom-up execution. The executive team sets the "what" and the "where," but the engineers and VPs determine the "how." This clarity is the only way to ensure that when we talk about application innovation, we are actually talking about business growth.
The maintenance-to-innovation seesaw
To operationalize our recovery, we adopted a “stability tax”: Sixty percent of effort went toward fixing core technical debt, leaving 40% for innovation. This wasn’t a magic number, but a tactical baseline to stop our teams from tripping over the rubble of the codebase.
The secret to consistency isn't holding to a fixed ratio forever; it’s evaluating your team's friction level. If releases are slow and complexity is high, your debt tax must go up. Because we were disciplined for three years, we’ve earned the right to flip that ratio. Today, we spend more on innovation, but we never drop the debt work to zero. Whether you are at 60 / 40 or 20 / 80, the rule is the same: You must pay for your past to protect your future.
Deciding to move on from legacy systems
One of the hardest calls a CTO makes is deciding when a system is too far gone. The temptation to burn it down and start over is constant, but in my experience, that decision must be driven by business strategy, not technical frustration.
At one point, Jimdo faced a strategic inflection point. We were moving from a DIY website builder, where users needed to know HTML and CSS, to a Web 2.0 era where we delivered the website to the user. Because the business model changed fundamentally, the existing solution became a blocker rather than a speed-booster. We isolated a team with the core responsibility to rebuild Jimdo 2.0.
This experience codified how I evaluate every major technical shift today. It taught me that a rebuild shouldn't just solve technical debt; it must solve a business problem. Now, when an engineering lead comes to me asking for a major investment in application innovation, I always come back to three simple questions:
How does this make us faster?
How does this make us less complex?
How does this improve product conversion?
If the proposal is tightly aligned with the company strategy and answers those three questions, we sign off and work for the quarter. Accountability is key. It’s not just about asking for a budget; it’s about making a business case for that investment.
Scaling experimentation through focused days
Innovation requires systems that enable experimentation without blockers. At Jimdo, we protect a focused day each week. This is at least one day where engineers can research tools, try out improvements to our existing codebase, and stay current with how the technology world is evolving.
As an engineer by heart, I believe that if you aren't researching and learning, you aren't staying relevant. With the rise of AI, this is more true than ever. AI is changing the game; it allows you to code significantly faster. But you can only win with AI if you have the proper guardrails in place. I incentivize our people to research these tools and find ways to get faster, and that investment in curiosity is already paying off.
We use internal communication channels to share these findings. When everyone is connected to the same goal and sees what their peers are building, it creates a healthy pressure to stay aligned.
The sunk cost trap: Lessons from a two-year failure
Not every application innovation effort works out. I’ve had my share of failures, including a very painful investment project that stayed up and running for more than two years.
The problem was that the market moved, our company strategy changed, and we were left with a half-baked project that no longer fit the business. It was incredibly painful to maintain. From that failure, I learned a vital lesson: Always break the work down into milestones that ensure we’re on the right path.
Think of it like building a car. You don't build four wheels and then an axle. You build a skateboard, then a bicycle, then a car. By delivering in small, complete increments, you protect yourself. If the strategy shifts or the market changes, you can pull the plug without losing two years of work. Agility isn’t just about speed; it’s about the responsiveness to stop when the direction is no longer right.
Application innovation is a mindset, not a milestone
There is no easy recipe for getting this right. It takes strong leadership to protect the engineering capacity required to pay off technical debt, especially when there is constant pressure to ship new features.
As the 2026 Cloudflare App Innovation Report demonstrates, the most successful organizations are those that expect and plan for large-scale application innovation over time. They don't treat technology as a static asset, but as a living system that requires constant care.
Application innovation is about making the time you spend on improving your applications count. By giving your teams the space to stay current, the clarity to align with business goals, and the discipline to pay down debt, you aren't just maintaining a product — you are building a competitive engine.
Scale your innovation
True application innovation is less about reaching a destination and more about evolving how your organization builds, protects, and deploys digital assets. To turn technical agility into a permanent business advantage, you need a foundation that removes friction while maintaining rigorous security standards.
Cloudflare’s unified application security and performance platform is purpose-built for this evolution. As organizations modernize legacy systems, optimize distributed architectures, and invest in AI-driven capabilities, Cloudflare provides the foundation that balances innovation with resilience. By integrating world-class performance, deep observability, and developer-centric tooling into a single programmable layer, Cloudflare helps you reclaim engineering time and drive innovation without the overhead of disparate tools or spiraling costs.
This article is part of a series on the latest trends and topics impacting today’s technology decision-makers.
Dive deeper into this topic.
Learn more about how organizations are modernizing their app stacks and processes in the 2026 Cloudflare App Innovation Report.
Author
Felipe Furlan — @ffurlansilva
CTO, Jimdo
Key takeaways
After reading this article you will be able to understand:
How to balance innovation with routine maintenance
When to rebuild, refactor, or invest in technical debt reduction
Criteria for evaluating modernization proposals