What we learn, build and share.

I hear this sentence surprisingly often at the moment. And most of the time, it has something to do with AI.

At Lupus, we are experimenting intensively with AI and building things that would probably have required an entire development team just two years ago. Along the way, we are noticing an interesting side effect: AI does not accelerate every person and role in the same way.

My business partner Jan loves going deep into the technology, experimenting and rethinking things from the ground up. I come more from the customer, product and application perspective. What interests me most is: which problem are we solving? What value does it create? How do we put it into practice?

We need both perspectives.

But AI is changing the relative pace between them. This became clear to me recently during a fairly mundane task.

Jan had developed our new CRM together with a technology partner and a great deal of AI support. My job was to test it and give feedback. So I wanted to create a traditional backlog: feature, bug, description, priority.

Jan’s response, in essence: “You can do that. But actually, things are done differently now. Why put so much effort into structuring everything while you capture it? Just document your observations. AI can then turn them into different structures, priorities and analyses.”

Suddenly, we were no longer discussing the bugs. We were discussing whether my way of documenting bugs was still up to date. That is exactly what I find so exciting. AI does not simply optimise our existing ways of working. It constantly challenges whether we still need them at all.

For me, this creates a new management task: we do not all need to go equally deep into AI. But we do need to learn how to keep bringing different speeds together.

Some people explore, build and think ahead. Others bring the customer, product and delivery perspective.

To me, AI readiness therefore does not mean that everyone knows the same amount about the technology behind AI. It means becoming faster together, despite moving at different AI speeds.

At least, that is something we are learning at Lupus right now.

I am helping a large energy company build its own IT hub in Portugal.

What does that mean in practice?

Many people primarily think about scaling or costs. In reality, it is a strategic question: what role should a hub play in the company over the long term, and which goals should it support?

And what is the biggest challenge?

I see one central strategic challenge and one important operational challenge:

• Scaling begins without an agreed target model
• Internal processes are not clearly aligned across all parties

OK – how do you approach that?

For us, clarity on these points is particularly important:

• What should the hub actually deliver?
• Which capabilities are needed internally?
• How will it be integrated into the organisation?

And what does the client gain from this?

• Scaling that actually works
• More ownership within teams
• Lasting value rather than short-term effects

What is your personal conclusion?

Many people simply build locations. Our aim is to establish the right capabilities.

How are you approaching this topic at the moment? We look forward to discussing it...

Less dependence on uncertain third countries. More control over key technologies.

It sounds like a political demand, but it has long been a business imperative. At a time of growing geopolitical uncertainty and fragile supply chains, companies need more than low-cost IT providers.

They need:

• Reliable partnerships
• Flexibility in resourcing
• Strong oversight – culturally, legally and operationally
• Competitive cost structures

Nearshoring offers all of this – when approached strategically:

• Locations with a strong talent pool and cultural proximity
• Models such as build-operate-transfer or in-house development centres
• Clear governance structures rooted in Europe

What we are seeing at Lupus & Company: Companies that deliberately invest in nearshoring reduce their technological dependencies, strengthen their resilience and actively contribute to Europe’s digital self-determination.

Digital sovereignty is not a buzzword. It begins with deciding where we build value – and whom we entrust with our core digital processes.

“We need the best IT resources! Fast. Scalable. And as cost-effective as possible.”

I keep hearing this sentence. But what often follows is a long list of requirements – everything has to happen at once. No compromises. No focus.

The problem?

Without clear prioritisation, IT nearshoring leads to disappointment.

What is the actual goal?

Cutting costs? Scaling? Securing know-how? Diversification? You cannot achieve everything at once – prioritisation is the key.

Which risks are acceptable?

Nearshoring is not merely a choice of location; it is a strategic question. Eastern Europe or perhaps Portugal? Your own legal entity or a partner model? A small partner or a large provider? The choice depends on the company’s priorities.

How will the organisation change?

Nearshoring is not plug and play. It requires new processes, cultural adjustments and management attention. Those who fail to prioritise this will fail.

My experience: Companies that pursue too many goals at once often end up with half-baked solutions. Successful nearshoring takes the courage to decide – and to prioritise.

#Nearshoring #ITStrategie #Priorisierung #Lupusandcompany