Software Product & Modernization Consultant

I have spent most of my career building software products—starting as an engineer, moving into product and architecture, and eventually building a company around industrial software.

Over the years, I have worked on point products, microservices-based SaaS applications, cloud and on-premise deployments, protocols, integrations, and large-scale industrial applications. This experience has made me less interested in technology trends and more interested in building systems that are practical, maintainable, and able to last.

I believe modernization is rarely about simply rewriting an existing application. The existing system usually contains years of business knowledge and rules, even if they are buried inside old code. The first step is to understand what the system is actually doing, why it is doing it, and what the business needs going forward. From there, the right architecture and modernization path can be defined.

Areas I Work In

Application Modernization

Every application that has been built, deployed and used over the years contains valuable business knowledge and intellectual property.

Before modernizing an application, it is important to understand the business rules, dependencies and logic that have evolved within it. A modernization exercise should not start with a technology decision. It should start with understanding the existing application and deciding what needs to be retained, changed, removed or redesigned.

The technology choices should then support that direction rather than forcing the business into a new technology.

Software Architecture

“Don't do serious work in the user thread.”

This has been one of my basic principles when designing software.

In a monolithic application, data input, business logic, user experience and presentation often become tightly connected over time. As the product grows, this makes every change more difficult.

Good architecture starts by asking the right questions—when, what, how and why. This helps create clear boundaries, understand the real constraints and leave enough room for the product to grow.

Architecture should serve the product and the business, not the other way around.

Microservices & Distributed Systems

Distributed architecture becomes important when applications need to handle scale, multiple customers, high volumes of data or independently evolving business functions.

Microservices and multi-tenant architecture should not be introduced as an afterthought. They need to be considered along with the business model, data flow and expected growth of the application.

I look at the complete flow of data and how it relates to the business outcome before deciding where services should be separated and where they should remain together.

Decisions such as cloud dependency, cloud-agnostic architecture, operating systems, deployment models and infrastructure are not only technical decisions. They have long-term business implications and should be considered early.

Application Integration

Most businesses have multiple applications that were built at different points in time. Getting these systems to work together is often more difficult than building a new application.

I work on application integration using APIs, messaging, databases and appropriate integration patterns.

Triggers, MCPs and AI agents are creating new ways of connecting applications and moving information with context. These technologies can be useful, but they need to be introduced for a clear purpose rather than simply because they are available.

Data Architecture

Data decisions cannot be made independently of the applications and business processes that use the data.

I work with data models, databases, migrations and data-intensive applications, with particular attention to how data is created, consumed, transformed and retained.

Moving data is often harder than moving code. A database migration or restructuring exercise needs to consider the applications, business rules, historical data, integrations and future requirements before the migration begins.

Protocol Implementation

My early career in software was closely connected with protocols and telecom.

That experience continues to influence the way I approach connected systems. I have worked on communication between applications, systems and devices, from application-level APIs to industrial and network protocols.

This includes protocol implementation, protocol conversion and forwarding bridges that allow different systems to communicate and exchange data in both directions.

SaaS Architecture

Building a SaaS product is more than making an application available in the cloud.

I have worked on multi-tenant SaaS platforms and the operational challenges that become visible as the number of customers grows.

Areas such as caching, centralized authentication and authorization, internal data exchange, single sign-on and integration between multiple applications become increasingly important as the product evolves.

The architecture needs to support not only the first few customers, but also the operational realities that come with scale.

Usability & User Experience

Software ultimately has to work for the people using it.

Understanding the user persona and how the user interacts with the application is an important part of architecture and product design.

My approach is:

User Experience → Data → Logic → Architecture → Implementation

The engineering should follow the experience we want to create for the user. At the same time, the design should leave enough room for the product to evolve as new users, workflows and business requirements emerge.

How I Approach Modernization

I don't start with “Which technology should we use?”

I start with:

• What does the existing system actually do?
• What business rules are embedded in it?
• Where are the current limitations?
• What needs to remain unchanged?
• What needs to change?
• Where is the data coming from and where does it need to go?
• What will the product need to support in the future?
• What is the simplest architecture that can support that future?

The objective is not to make an old application look modern.

The objective is to build a system that the business and engineering team can continue to evolve.

If you are dealing with a software modernization, architecture, integration or product engineering problem, get in touch or explore the related articles.