Oper’s Six-Market Blueprint: Building Pan-European SaaS with One Codebase

Most SaaS companies talk about “going global” from day one. The reality? They struggle to expand beyond their home market for years.

Different languages. Different regulations. Different banking practices. Each new market becomes its own customization project until you’re maintaining six different products pretending to be one platform.

Geert Van Kerckhoven saw this pattern everywhere. Banking technology companies would enter new European markets by forking their codebase, creating market-specific versions that diverged over time.

In a recent episode of Category Visionaries, Geert Van Kerckhoven, CEO and Co-Founder of Oper, explained why reaching six live European markets with a single codebase became the milestone they celebrated harder than any revenue number.

The Thesis That Had to Be Proven

Before the financial crisis, building pan-European mortgage software was nearly impossible. Each country had its own regulatory framework.

But Geert noticed something changing. “The European Union was trying to harmonize more the mortgage rulings,” he explains. Post-crisis regulations were creating more consistency across borders.

This opened a window—not to build different products for each market, but to build one platform that could flex across multiple European regulatory environments.

The thesis: You could build truly pan-European mortgage technology if you designed for variability from the start. Not customization. Not market-specific forks. Actual platform flexibility.

But a thesis is just a thesis until you prove it works.

Why This Milestone Mattered

When Oper reached six European markets live with a single codebase, Geert’s team celebrated. “That was for us, like all, let’s say, mid sized to larger financial institutions. That’s something we’ve celebrated really strongly,” Geert says.

The celebration wasn’t about customer count or ARR. It was about validation. “For us, it really meant that this pan european software, which has been really hard to do, got validated.”

Think about what that validation actually means. Six different countries. Six different regulatory environments. Six different languages. Multiple different banking practices. All running on the same core platform.

That’s not a feature launch. That’s proof your entire business model works.

The Architecture Decision

The temptation in multi-market expansion is to handle differences at the surface level. Different UI for Germany. Different workflows for France. Same core, different skins.

That breaks down quickly in mortgage technology. The differences aren’t cosmetic—they’re fundamental. How you calculate affordability varies by country. What documents you need varies by jurisdiction.

Oper’s solution was building flexibility into the platform architecture itself. Not customization layers on top of a rigid core, but a core designed to handle regulatory variance as a first-class concern.

“We really take on the origination journey. We basically bring it to the, let’s say, 21st or even 22nd century by reducing paper and by using technology intelligently,” Geert explains. But doing that across multiple markets meant the intelligence had to be multi-jurisdictional from the start.

The Design Partner Strategy

Oper’s first customer played a crucial role in this validation. “If this is what you guys are going to build, I’ll happily be your first client. And I want to act as a design partner,” they said.

That design partnership created something valuable: a customer who understood they were helping build something bigger than a point solution.

But the real test came with markets two, three, and four. Each new market tested whether the architecture decisions held up. Could you add a new regulatory framework without breaking existing implementations?

“Still one of our client today and still super happy of using opera and like taking in all our new features,” Geert notes about that first design partner. The “taking in all our new features” part matters—features built for new markets benefit existing ones. The platform gets better for everyone as it expands.

Choosing Milestones That Actually Matter

Most founders track ARR, customer count, team size. These are reasonable metrics. They’re what investors ask about.

But Geert’s insight was recognizing that for Oper’s specific business model, six live markets with one codebase was more important than revenue milestones.

Why? Because that milestone validated the entire thesis the company was built on. Revenue can grow through brute force—more sales reps, more markets, more customization. But sustainable revenue from a truly pan-European platform? That only happens if your core architecture actually works.

This principle applies broadly: choose milestones that validate your business model, not just milestones that look good in investor updates.

If you’re building developer tools, the milestone might be adoption by companies with radically different tech stacks. If you’re building security software, it might be passing audits in three different regulatory regimes. If you’re building collaboration software, it might be retention across companies with completely different org structures.

The point is identifying what needs to be true for your business to work at scale—and celebrating like crazy when you prove it.

The Community Multiplier

Reaching six markets with one codebase creates a second-order benefit: you can bring those markets together.

“We bring together our clients and our prospects. So we build communities,” Geert explains. When a German bank and a Swiss bank and an Austrian bank are all using the same platform, they can learn from each other. Best practices from one market inform implementations in another.

This wouldn’t be possible if each market ran a different fork of the product. The community effect requires actual commonality, not superficial similarity.

The Implication for International Expansion

Most advice about international expansion assumes you’ll customize heavily for each market. The conventional wisdom is that respecting local differences means building local solutions.

Oper’s approach suggests a different path: design for variance from day one, then prove you can actually serve multiple markets with that single design.

The challenge is resisting the temptation to customize your way into new markets. Every country-specific feature is a bet against platform uniformity. Every special case is technical debt that makes the next market harder.

But if you can build true platform flexibility—if you can reach six markets with one codebase—you’ve built something that actually scales. Not just in theory. In practice.

For Geert and Oper, proving that was worth celebrating. “For us, it really meant that this pan european software, which has been really hard to do, got validated.”

That validation is worth more than any single revenue milestone. It’s proof your business model works.