“Modernization doesn’t have to mean burning everything down” – TSH’s CTO Adam Polak about the challenges of software modernization

Business owners often believe that modernization is risky and time-consuming. What’s more, their tech leaders fail to show them how removing the so-called technical debt could improve profits. Adam Polak has a recipe for both, a methodical approach that minimizes risks and allows you to deliver value faster.

‘The worst thing is when developers come back and tell you: “It’s not possible.”’

Why do some businesses allow their systems to get to the point where they can’t add new features fast enough because of the technical debt?

The Software House’s CTO, Adam Polak, has participated in many modernization projects and believes all project stakeholders must change their approach to battling technical debt.

In this interview, he shares:

Say hello to Adam!

Meet Adam Polak

Adrian Senecki: Hello, Adam! You’ve been at The Software House for more than 10 years now, but only as a CTO in the last few months.

How do you feel about the new role? How different is it from your previous responsibilities as Head of Node or VP of Technology?

Adam Polak: I wouldn’t say it’s that different.

Whether as a Head of Node, VP of Technology, or CTO at a services company, my main job has always been to act as an advisor and help deliver the most business-efficient solution to whatever challenge the client brings.

As Head of Node, I helped clients who worked with Node.js. As VP of Technology, I was the CTO's right hand. I stepped in when the CTO was unavailable, so I was already heavily involved in making decisions.

Then, when I became CTO, I got involved in the majority of the decision-making and sales processes at the company.

Beyond selling services, I know you are also strongly interested in effective delivery. Recently, you launched the Effective Delivery newsletter.

Tell us more about it.

It’s not just mine. Our Head of Development, Andrzej Wysoczański, is also heavily involved. It’s a joint effort, much like the Taby vs Spacje podcast we’re both running.

In the Effective Delivery newsletter, we’re trying to identify patterns other companies can replicate, things that help teams extract more value from their apps.

From what I’ve seen, a big part of the newsletter is also about how you organize your technical teams for efficient delivery. For example, recently you talked at length about Team Topologies.

Yes, but I wouldn’t say that it’s the primary focus. It’s the first topic we tackled, but many more ideas are coming.

Team Topologies felt like a good place to start because many companies are already doing it without even realizing it. Unfortunately, the same fact also means that they don’t often do it very efficiently.

Can companies learn this from their tech provider, not just buy services, but also organize their teams better because they cooperate with them?

Efficient delivery is something you learn by observing others or having someone with a different perspective come in and enable you.

Team Topologies have the concept of an enabling team, a small task force that joins a project to perform a specific job and passes on expertise to the main team. We use this concept internally a lot.

So it’s worth learning from others' mistakes and experiences. It’s a bit like what happened with Scrum. Everyone started moving toward it. Some companies failed, while others made it work well and kept pushing further.

Over time, we’ve seen some flaws in Scrum. That’s when the need for a different approach began to emerge.

I wouldn’t call Team Topologies an “advanced” approach, just a different one. It gives you a way to divide your organization contextually. It's less about fixed team structures and more about optimizing for efficient delivery and product focus.

Living with legacy systems

2025 is a good time for companies to finally address legacy systems' impact on business delivery. AI capabilities are becoming more common and too much for older systems to support.

But why do you think tech leaders often struggle to explain the consequences of technical debt to the rest of the organization?

The technical team doesn’t always communicate in a way that makes sense to non-technical people.

When writing code, you care about quality, what libraries you use, and how clean the code is. That’s what technical debt directly affects.

The speed of delivery plays into that, too; the faster you’re expected to deliver, the more corners you have to cut. Sooner or later, that piles up into technical debt.

By the time the business says, “Let’s do AI,” it’s often too late. Developers might say, “It’s not possible.” And that’s when people suddenly start questioning how the platform was built and whether it needs to be rewritten.

But here’s the thing, if developers could explain the problem differently earlier, they’d get much more support.

I remember this story about a team that wanted to refactor their deployment pipeline. They said, “We’ve got tech debt in the pipeline. We want to fix it.” It was a total failure. No one cared.

But then, the product manager asked, “Okay, what would you do?”. And they said, “Well, our builds are getting slow. We think we can cut build time by 75%, but we’ll need two weeks.”

In his head, the PM did the math: faster builds = more features delivered faster = better output. Two weeks? Worth it.

Speaking of business value, do you think tech leaders can calculate the cost of technical debt to the company?

If you monitor those numbers and notice they increase, I can guarantee something’s wrong. Delivery is slowing down.

The root cause could be many things; it may be that too few people are assigned to the job, or that the software itself is working against you.

So there are many possible root causes and ways to address the technical debt.

But speaking specifically about AI, would you agree that most legacy systems today require significant modernization efforts to support features such as MCP?

The good part of MCP is that it was built modularly. You often don’t need to integrate it directly with legacy systems. You can connect straight to the database, expose some APIs, and skip the legacy stack entirely.

That’s also why you see so many AI agents and MCP servers developed as open source. People know they don’t have to deal with the whole legacy infrastructure. They just hook into a data source or an endpoint and go.

If you do want to make MCP part of the legacy system itself – not as a separate box, but embedded deeply inside, it can get tricky. The difficulty depends on how the system is structured and what tools you’re using.

The cost of not modernizing your software


What’s the risk of delaying modernization for too long? Say the system is way overdue, but the business keeps postponing it.

If you’re a product company and you want to build something just for internal use, it may be okay to look for lengthier workarounds.

But what if your biggest client comes to you and asks for a feature, and you can’t deliver it quickly

We’ve seen that exact situation. A client’s largest customer asked for something, and because of all the shortcuts taken over the years, that feature was practically impossible to build using the usual process.

That’s the nightmare scenario. You’re stuck. You can’t help your most important customer. And then the thought starts to grow in their head: “Maybe it’s time to work with someone else.”

And, despite everything we’ve discussed, why do you think some companies still treat modernization as a luxury?

We must look back at what people mean when they say “modernization.”

For many, it means switching to some shiny new technology. It sounds like a complete rewrite. And when people hear that, they think, “Oh no, this will be huge. It’s going to cost a lot. It’ll take years to pull off.”

It’s like renovating your house. When you even consider it, you may go, “Nope, I don’t want to deal with something like that.”

Many modernization projects assume that everything has to be done at once. And when the scope feels massive, business leaders hesitate. After all, the app still works. It brings in money. Some customers might not love everything about it, but they’re still using it. The thinking is: “It’s not ideal, but it’s fine. Let’s postpone modernization.”

Can you think of any examples from past projects where postponing modernization caused real problems for the business? When did it become clear they waited too long?

In my experience, by the time we get involved, the company usually already knows it’s its last call. That realization is often what brings us in.

So, I can’t point to a specific time, but I can go back to the story I mentioned earlier, where a company knew it had waited too long.

Their biggest customer came to them and asked for a new feature. They said, “Either you build this, or we leave.”

The good news is, they managed to pull through in the end. But the situation itself isn’t uncommon.

Getting a buy-in for modernization

At this point, we’ve already come up with many ideas that could help a tech leader convince other stakeholders that modernization is necessary. Let’s reiterate them.

The Software House offers Platform Modernization Roadmap Sprint™. I wonder if a sprint like that could help tech leaders get buy-in for modernization. I think that even if they can’t get a buy-in for a full-blown modernization, they can perhaps convince stakeholders to do a 2-week workshop. It’s a smaller investment, right?

To relieve it, you start with a plan. And it shouldn’t be just a timeline. The plan should provide a strategic view of what you have and what needs to happen.

The idea is to divide the system like so:

• What should stay as it is?

• What can we remove altogether? (We've had cases where removing unused features led to more revenue.)

• What can be offloaded to third-party providers? (Instead of rebuilding your CMS, it may make more sense to subscribe to one that already works.)

• What needs to be rewritten?

In doing so, you can discover a sensible process for moving from legacy to a modern, flexible, fast-moving system. You can also find that large parts of your system don’t need rewriting.

This is the kind of plan we help clients figure out during the workshop.

So, during these two-week sprints, tech leaders might discover that there is much less to rewrite than they thought.

Exactly.

Our approach is all about showing alternatives to what’s currently in the system.

So instead of focusing on real business value, these teams spend time adding features to something someone already did years ago.

The Platform Modernization Roadmap Sprint™ provides a step-by-step modernization plan that ensures efficient transition to an upgraded system, without disrupting the business in the process

The app modernization business plan


There is an out-of-the-box solution for nearly everything. Is finding them for the client in question part of giving them the most straightforward way of achieving their modernization goal?

It’s a part of it.

We deliver a metric-based breakdown. We map all the features into categories: what we keep, what we remove, what we replace with something else, and what we rewrite.

Beyond that, we also map how each decision impacts business value. There's another angle, too – what’s easy to change and what brings the most value.

You can build a graph. The bottom left is easy and low-cost, the top left is easy and expensive, the top right is complex and costly, and the bottom right is hard and cheap.

With that, you can make intelligent decisions. Do you want to invest time in rewriting something that is expensive and won’t bring much business value? Or do you start with something that’s easy and brings clear benefits?

Only after that comes the timeline, what to focus on first, second, third. You get structure: how the team should be built, how much each phase will cost, etc.

During the sprint, while building the modernization roadmap, is it possible to discover business benefits that the company didn’t expect beforehand?

That’s a key part of the process.

That might sound small, but once they explained how their business works, that 0.5% translated to millions.

Once you know the goal, you can start mapping how to get there.

It could mean enabling the business to deliver critical features more quickly, or helping the marketing team create landing pages and A/B tests faster.


There are many ways to reach a business goal. That’s why the sprint isn’t just about systems and architecture. It’s also a discovery process for the business itself.

It’s not, “Here’s your system, let’s draw the roadmap.” It’s, “Let’s figure out where the business wants to go, and then we’ll work out how tech can help get it there.”

So, they typically know what they want to achieve, but you help them achieve it most effectively and painlessly.

That’s right.

However, some tech leaders might feel they know their system best, so why bring in outside help?

Why is an external partner a good idea? Is it about bringing a fresh set of eyes?

You should always have an external perspective. I see it even with our internal teams. There’s a reason why they often want to consult with an architect who knows nothing about the project.

It is easy to develop a bias when working on a system for a long time. You know how it works and how the team around you operates. So when you start thinking about solutions, you subconsciously factor everything in.

Sometimes, those “naive” questions can be game-changers. For example, “Why are you doing it this way?” or “Have you tried this alternative?” They might initially feel uncomfortable, but they often lead to breakthroughs.

Is it just about a fresh perspective or the unique skills of serial app modernizers?

It’s about skills as well. There are a lot of approaches and patterns specific to modernization.

Architectural strategies, tools that can make the process easier, ways to break things down – they’re not always obvious. When you do it for the first time, you’d have to spend a lot of time researching them.

App modernization resources

We typically end each interview with a recommendation of resources that could help our readers learn more about the subject at hand.

But before we get to such resources, I wanted to ask you if a workshop like the one we talked about could also be an educational tool for companies that may not be considering modernization yet, but want to gain the right know-how so that they can do it themselves in the future.

A workshop like this can be a great way to get early insights – ideas on what could be done in the future to make the system better, easier to maintain, or more scalable.

The key is that you already have a solid, validated plan by the sprint's end. You’ve got something reviewed by experts who said, “Yes, this is doable.”

Are there any other resources you’d recommend to tech leaders considering modernization?

Books will not replace hands-on knowledge, but some reliable positions could enhance your general knowledge.

I learned a lot from Martin Fowler's books, including “Refactoring", “Patterns of Enterprise Application Architecture", and "Enterprise Integration Patterns".

Martin Fowler's books on app modernization

What’s next? 5 app modernization actions for you to take

Did Adam inspire you to rethink your attitude towards technical debt?

Just remember:

1. Focus on business outcomes – if you are in a position to advocate for app modernization, find a way to show how fixing tech will help make more profit.

2. Link modernization to your ability to deliver – talk about your new system’s potential ability to provide new high-impact features.

3. Think of modernization as evolution, not revolution – you can break it down into small goals that can be achieved without disrupting the business.

4. Set a clear modernization goal – figure out a goal you’d like to achieve through the modernization process. For example, you might want to improve your conversion rate.

5. Get a fresh set of (expert) eyes – external experts will provide an outside perspective and tried-and-true methods for delivering modernization projects.
   
   Good luck with your next app modernization project!

   Check out the Platform Modernization Roadmap Sprint™ to skip trial & error and get an efficient and risk-free plan to upgrade your system.