Why Pagos Stopped Waiting for Perfect and Started Shipping Weekly Data Files

Why Pagos Stopped Waiting for Perfect and Started Shipping Weekly Data Files

Enterprise founders face a paralyzing dilemma. Customers want sophisticated features. Building those features takes months. But you need to prove demand before investing engineering resources.

Most founders resolve this by either overbuilding (wasting time) or underwhelming customers (losing deals). Pagos found a third path.

In a recent episode of Category Visionaries, Klas Bäck, CEO and Co-Founder of Pagos, a payments operations platform that’s raised $44 million in funding, explained how they delivered enterprise value with decidedly non-enterprise implementation.

The Customer Request That Could Have Taken Months

Early adopters wanted automation. The ideal solution was obvious: a fully integrated feature in the Pagos platform. Real-time data. Beautiful interface. Scalable architecture.

Building that properly would take months. Pagos had a choice: tell the customer to wait, or find an interim solution.

“We want to automate this. It should be in the online app that we have. But we can start if you let us send you a file of data once a week,” Klas recalls.

A weekly data file. Not elegant. Not scalable. But it solved the customer’s problem right now.

The Evolution From Weekly to Streaming

The weekly file proved the value proposition. Customers used it. They came back wanting more.

“And then they became a daily file and then they became a streaming file as an example,” Klas explains.

Each iteration validated demand while moving toward the ideal implementation. Weekly proved the concept. Daily proved customers wanted fresher data. Streaming became obvious once demand was undeniable.

“Otherwise it would have been too big of a lift in the short term, but it was valuable for them, so were lucky enough to do it.”

Why This Approach Works for Enterprise

Conventional wisdom says enterprise customers demand polish. But this misunderstands what enterprise buyers actually value.

Sophisticated customers care about outcomes, not implementation details. They understand the difference between “we can’t do that” and “we can do that now with this approach, and we’re building a better version.”

When Klas tells customers they’ll start with a weekly file, he’s demonstrating responsiveness. The customer gets value immediately instead of waiting months.

This approach also filters for genuine demand. Customers who actually need the feature accept the interim implementation. Those requesting it casually often decline the imperfect solution. This sorting mechanism saves engineering time.

The Build Decision Framework

The weekly-to-streaming evolution illustrates a principle about enterprise product development. The question isn’t “what’s the right solution?” It’s “what’s the minimum viable implementation that proves this is worth building properly?”

A data file requires minimal engineering. You’re essentially automating a manual export. No new UI. No new infrastructure. No complex edge cases.

But it delivers the outcome customers need: automated access to data they can integrate into their systems. Implementation details matter less than the fact that it works.

When Early Adopters Force Your Hand

This approach emerged from necessity. “We have a lot of early adopters. So in a way we’ve been kind of forced to build out at least some sort of pilot version of some of the things that was more long term,” Klas explains.

Early adopters push you to solve real problems with real urgency. They’re willing to tolerate imperfect solutions if you’re responsive about the roadmap.

The weekly file approach resolves this tension. You can say yes to customer requests without overcommitting engineering resources.

The Technical Debt Question

Won’t building interim solutions create maintenance burden? Sometimes, yes. But the alternative is worse. Building the perfect solution before validating demand creates product debt: months invested in features customers might not use.

The Pagos approach creates technical debt intentionally. “We have a lot of things where we built one version, 1, 2, 3. But we say, hey, for many more companies to be able to try it, we need to add features.”

Version 1 proves the concept. Version 2 handles more edge cases. Version 3 becomes the scalable platform feature. Each step is justified by validation from the previous step.

The Communication Strategy

Making this work requires transparent communication. Enterprise customers need to understand they’re getting version 1, with version 2 and 3 on the roadmap.

“Staying close with communication, making sure everyone understand where we are and what’s going on, being transparent, if something happened that shouldn’t have happened and make sure that put in processes and procedures to try to make sure that never happen again.”

This transparency builds trust. Customers see the product evolving in response to their usage.

The Action-First Principle

The weekly file approach embodies a broader philosophy. “At the end of the day you just got to go for it,” Klas explains. “Like, hey, not everything is perfect. It is a startup, it is understood and ideally you get everything right, but sometimes you don’t. And then how you fix it and how you manage it matters a lot.”

Analysis paralysis kills startups. You can spend months debating the right architecture. Or you can ship something imperfect that proves demand and teaches you what matters.

The companies that win aren’t those with the best initial implementation. They’re the ones that learn fastest from real customer usage.

The Replicable Framework

For founders facing similar build-versus-wait decisions, the Pagos approach offers a tactical framework:

Identify the core outcome customers actually need. Ask what’s the simplest implementation that delivers that outcome. Ship it quickly, with transparent communication about the roadmap. Let usage patterns inform the next iteration. Build the scalable solution only after proving demand.

This doesn’t work for every feature. Some capabilities require substantial upfront investment. But for a surprising number of enterprise features, there’s a simpler interim solution that proves value before you commit to building it perfectly.

The weekly file that became daily, then streaming, represents more than clever product development. It’s a philosophy about how to build in uncertainty: move fast, prove value, iterate based on reality rather than assumptions, and let customer usage guide you toward the right solution.