The Second Client Problem: How Oper Avoided Building Proprietary Software for One Customer

The Second Client Problem: How Oper Avoided Building Proprietary Software for One Customer

Signing your first customer is euphoric. The validation. The revenue. The proof that someone will actually pay for what you’re building.

Then reality sets in. You’ve built exactly what that first customer needs. Every feature prioritized for their workflows. Every decision shaped by their feedback.

And now you need to find a second customer.

In a recent episode of Category Visionaries, Geert Van Kerckhoven, CEO and Co-Founder of Oper, explained how his mortgage tech platform navigated this trap—and why finding that second customer quickly was more important than celebrating the first.

The Hidden Trap of Design Partners

When Geert pitched Oper’s vision—bringing mortgage lending “to the, let’s say, 21st or even 22nd century by reducing paper and by using technology intelligently”—he found an eager first customer within three months.

“Look, 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,” the prospect said.

Perfect, right? A customer willing to pay from day one and help shape the product. Most founders would celebrate and dive into building exactly what that customer needs.

But Geert recognized the danger immediately. “The challenge we of course had was we had to prove very quickly we could find a second client,” he explains. Why? “To avoid we would build something proprietary for that first client.”

Read that again. The challenge wasn’t celebrating the win. It was avoiding the trap hiding inside it.

What Proprietary Software Disguised as SaaS Looks Like

Here’s how it happens: Your design partner has specific workflows. You build features to match those workflows. They have particular integrations. You prioritize those integrations.

Six months later, you have happy customer number one and a product that perfectly solves their problems. You also have software so tailored to that customer that selling to anyone else requires rebuilding half your platform.

You’ve built proprietary software disguised as a SaaS product.

This is especially dangerous in specialized markets. Banks don’t all operate the same way. If you build too specifically for customer one, customer two becomes exponentially harder.

The revenue feels real. But you haven’t validated product-market fit—you’ve validated that you can build custom software for a paying customer. That’s a services business, not a platform.

The Speed Test

Geert’s insight was recognizing that time was the critical variable. The longer you build for one customer without finding a second, the more proprietary your software becomes.

Every sprint building features for customer one without validating they work for customer two deepens the hole. Every month without a second customer proves you’re building custom software, not a platform.

So Geert made speed the priority. Find the second customer quickly. Before the platform ossifies around customer one’s needs.

“We also succeeded in that eventually,” Geert says about finding that second customer. They didn’t wait until the product was “ready.” They started selling to customer two while still building for customer one.

The Design Partner Relationship That Actually Worked

The remarkable thing about Oper’s first customer is they stayed. “Still one of our client today and still super happy of using opera and like taking in all our new features,” Geert notes.

That phrase—”taking in all our new features”—reveals everything about how they managed the design partner relationship correctly.

If you build proprietary software, new features don’t make sense for the original customer. They’re building for other customers now. The platform diverges from their needs.

But if you build a real platform, new features built for customer two, three, and four also benefit customer one. The platform gets better for everyone as it expands. Customer one isn’t losing your focus—they’re gaining the benefits of serving a broader market.

This only works if customer one understands they’re not buying custom software. They’re partnering to build a platform. “I want to act as a design partner,” that first customer said. Not “build exactly what I need.” Design partner implies building something bigger.

The Architecture Decision

Avoiding proprietary software requires architectural discipline from day one.

When customer one requests a feature, you can’t just ask “does this solve their problem?” You must also ask: “Will this work for customers we haven’t met yet? Does this generalize?”

Some features are clearly general: digital document upload, workflow automation. These solve problems every mortgage lender has.

Others are market-specific: regulatory compliance, particular calculations. These need flexible configuration, not hardcoded features.

The discipline is building the right abstraction layer. Not “here’s how Swiss banks calculate affordability” hardcoded. But “here’s a flexible calculation engine that can handle multiple methodologies.”

That’s harder to build. It takes longer. But it’s the difference between a platform and proprietary software.

The Credibility Advantage

Oper had one major advantage: credibility.

“I mean, I had built already at that time maybe eight or nine similar systems, proprietary and more on prem software. So we did really know what to do,” Geert explains.

That track record gave customer one confidence. But it also gave Geert the authority to say no. When customer one requested something too specific, Geert could credibly explain why building for a broader market would ultimately serve them better.

Without that credibility, founders face pressure to build whatever the paying customer wants. With it, you can have architectural discipline even when revenue depends on that first customer.

The Principle Applied

The second customer problem isn’t unique to mortgage technology. It appears whenever you have:

• Enterprise customers with significant customization needs
• Complex products where “MVP” still requires substantial features
• Markets where customers expect tailored solutions
• Long sales cycles that make customer two feel far away

The solution is always the same: create urgency around finding customer two. Don’t wait until customer one is “done.” Start selling before you feel ready. Prove you can find multiple customers before you’ve architected yourself into a corner.

And choose design partners who understand they’re not buying custom software—they’re partnering to build a platform.

For Oper, that discipline paid off. They didn’t just find a second customer. They found six European markets running on a single codebase. But it started with recognizing the danger hiding inside their first win and moving fast to avoid it.