When to modernize: how a CEO knows the moment has come

Most modernization decisions are made late. Not because the signals are missing, but because there is always a reason to wait. This post is about the decision itself: how to recognize the moment, what to decide fast, and what to take time over.

The worked example is Moonfare, a private markets platform managing about $4 billion across 130 funds. Co-CEO Lorenz Jüngling described the decision on the Swimm Podcast.

Legacy arrives faster than you think

Moonfare’s platform was built in 2018 and never replatformed. Seven years later, it had 5,500 investors and roughly 10,000 share classes to serve them. More share classes than investors. Each one was the remnant of an experiment.

That is how legacy forms. Not through old technology, but through accumulated edge cases, sediment from tests, and decisions that turned out to be one-way doors. In private markets, a fund investment locks an investor in for ten years. Every “test” distribution channel or fund type became a permanent part of the ecosystem.

A platform does not need to be decades old to be legacy. It needs to have accumulated more complexity than the organization can reason about.

The signal: development slows until every idea becomes a question of time

The wall came when it was clear that continuing on the existing platform meant every improvement would take too long to deliver the value investors expected. Development time, not technology, was the business signal.

Jüngling’s reflection is the most useful part of the story. He has never made a modernization decision too early. Most were made too late.

Whenever there is doubt, there is no doubt

His rule, borrowed from a film: whenever there is doubt, there is no doubt. If you doubt that your current platform is the right one, it almost certainly is not.

The practical version: decide fast whether to change. Take time to decide how. The time spent gathering more information about whether rarely changes the answer. It only makes the eventual change more complicated.

Ask engineering a different question

A pattern Jüngling describes from his own mistakes: the business arrives with a solution, engineering says yes, and nobody asks whether the solution makes sense. Engineers want to solve problems. Asked “can you build this?”, they will say yes.

The better question is “does it make sense to build this?” Often an alternative delivers 80 percent of the business value at 20 percent of the effort. Calling business outcomes “non-negotiable” before the work starts removes the chance to find out.

Much of a modernization decision is a communication problem between business and engineering, especially in companies where technology enables the product rather than being the product.

The hardest part is organizational

Moonfare ran three transformations at once: the platform, the way software is built, and the team. Jüngling underestimated the emotional complexity.

People had spent years building the existing platform. Some had chosen technologies because they wanted to learn them. Asking them to abandon that work, and to change how they work, is hard. Not everyone wants to. The team changed significantly as a result.

Two things helped:

• Business training for engineers. Sessions on how private markets investing works, so engineers could understand requirements and become partners to the business rather than recipients of tickets.
• Leadership doing the same work. Jüngling took a coach and learned to build with AI himself, working with Claude Code daily on his own managerial tooling. It gave credibility to asking the team to rethink how they work.

Build versus buy, and the four-week bet

Moonfare brought Swimm in for an external assessment that framed the problem and the plan. Then the engineering team asked to do it themselves.

Jüngling gave them four weeks to prove it. There was no factual test that would have settled it. The decision was about ownership and passion: if the team wanted the first shot that badly, killing that would have been the bigger risk.

He is clear about the trade-off. The external route would likely have been faster and the outcome less risky. The internal route brought the team together and built capability that stays. The open question with any external rebuild is drift afterwards: a clean codebase that nobody maintains starts rotting immediately.

His advice: use experts to frame the problem and assess it. Give your team space to own the execution. Both can work. Choose based on how the team is doing at that moment.

What AI changed

AI made the rebuild feel doable. Individual developers could use it to understand legacy code, disentangle it, and move fast enough that clearing the backlog seemed manageable.

Moonfare then built an internal software factory. Today an agent coordinates the steps and writes about half the company’s code from written requirements. The engineering team went from 52 to a planned 18, with those 18 already producing twice what 52 did. The error rate stayed constant. Nothing ships without human review.

The next constraint is organizational again: how the rest of the business interacts with technology, and how to avoid building everything anyone ever wanted. Moonfare kept six-week cycles with explicit business cases, doubled product management capacity, and hired more senior people.

Advice for a CEO who has been postponing

1. Whenever there is doubt, there is no doubt. Decide to change fast.
2. Spend the time on how, not whether.
3. Combine external experts with space for your own team.
4. Accept that you will not fully control it. It can bring the company together.
5. The code freeze you fear rarely happens.

Swimm’s Assessment stage is built for the first step: a snapshot of the tech stack and modernization fit, with a scoped plan, risks, and success criteria. It gives a CEO the framing to decide fast and the plan to decide how.

Swimm is a product-enabled service company. We combine deterministic analysis for accuracy, AI for scale, and SMEs to catch what tools miss. Book a 30-minute scoping call.

FAQ