The Rooom Pivot: From Custom Automation Projects to Platform Company

Hans Elstner spent months building automation projects before he noticed the pattern. Here’s what he learned about finding your platform inside your services business.

Every founder doing consulting work tells themselves the same story: this is temporary. We’re just doing services to fund the product. But most never make the jump. They stay trapped in the high-margin, low-leverage world of custom work, always one project away from building the real business.

In a recent episode of Category Visionaries, Hans Elstner, CEO of Rooom, shared how he escaped this trap. His team spent months building automation projects for clients before recognizing the platform hiding in plain sight. The pivot from services to product wasn’t obvious—it required paying attention to patterns most founders miss.

The Services Trap That Catches Everyone

Rooom didn’t start as a platform company. Like many technical founders, Hans and his team began by solving specific problems for specific clients. “We built a lot of automation projects, classical automation projects with using some of the tools out there,” Hans recalls.

The work was good. Clients paid well. The projects were interesting. But something felt off. Each new project required starting from scratch. The team couldn’t leverage previous work. Every client engagement consumed the same amount of time regardless of how many projects they’d completed before.

This is the services trap. You’re selling time, not leverage. Revenue scales linearly with headcount. Growth means hiring more people to do more projects. There’s no compounding, no efficiency gains, no way to serve 100 clients without 100x the resources.

Most founders recognize this intellectually. But they stay stuck because services revenue is immediate and certain. Platform revenue is distant and uncertain. The rational move is to keep doing what’s working—until you notice the pattern.

The Bottleneck That Kept Appearing

Hans’s breakthrough came from paying attention to what kept breaking. Across different clients, different industries, different use cases, the same problem appeared repeatedly.

“We realized that extracting data from documents was a big bottleneck,” Hans explains. “So we said, okay, this is actually the thing that we could bring the most value.”

Every automation project hit the same wall. The workflows worked perfectly—until they encountered documents. Invoices, contracts, forms, receipts. Unstructured data that resisted automation. Each project required custom code to extract data from documents specific to that client.

This repetition is the first signal. When you’re solving the same problem repeatedly across different contexts, you’re not doing custom work—you’re doing the same work in custom clothing. The solution might look different for each client, but the underlying problem is identical.

The Mental Shift From Project to Platform

Recognizing a pattern and pivoting to a platform are different things. Hans had to make a fundamental mental shift about what Rooom was building.

In services mode, the question is: How do we solve this specific client’s problem? In platform mode, the question becomes: How do we solve this class of problems once, for everyone?

This shift changes everything. Instead of optimizing for client satisfaction on individual projects, you optimize for abstraction—finding the common denominator across all projects. Instead of building custom solutions, you build composable components that clients can configure themselves.

For Rooom, this meant stopping custom document extraction projects and building a platform that could handle any document type. The solution wouldn’t be perfect for any single use case, but it would be good enough for most use cases—and infinitely more scalable.

The Scary Economics of Pivoting

The decision to pivot meant walking away from revenue. Services clients wouldn’t pay for a platform that didn’t exist yet. Platform clients wouldn’t materialize until the product was ready. There’s a gap—sometimes months, sometimes years—where you’re burning cash with no incoming revenue.

Hans doesn’t sugarcoat this reality. The pivot was a bet that platform economics would eventually dominate services economics. One platform customer would generate more lifetime value than dozens of services projects. But only if they could survive the transition.

This is where most services-to-platform pivots fail. Founders try to do both simultaneously—keep servicing existing clients while building the platform. It sounds rational, but it rarely works. Services work expands to fill available time. The platform always gets deprioritized because clients are paying today for services but won’t pay until tomorrow for the platform.

Hans made a cleaner break. Rooom became a platform company, not a services company that happened to have a platform. The focus clarified. The organization aligned. Everyone understood what they were building and why.

How to Recognize Your Platform Opportunity

Hans’s experience reveals specific signals that indicate when consulting work is hiding a platform opportunity. These aren’t theoretical—they’re practical patterns you can look for in your own business.

First, repetition across clients. If you’re solving the same core problem for multiple clients, regardless of industry or use case, there’s platform potential. The problem doesn’t need to be identical—it needs to be analogous. Document extraction for invoices and contracts are different use cases but the same core problem.

Second, custom work that doesn’t require customization. Often you’re building custom solutions because that’s what clients expect, not because the problem actually demands it. If your “custom” solutions are 80% similar with 20% variation, you’re building a platform with poor packaging.

Third, integration patterns that repeat. When every project requires connecting the same types of systems in similar ways, you’re building infrastructure, not applications. Rooom kept integrating with automation platforms. That pattern suggested partnerships and integrations should be core to the platform strategy.

Fourth, margin compression over time. If your services margins are shrinking as you take on more projects—because the work is getting commoditized—that’s a signal the market is ready for a platform solution. What clients paid premium prices for yesterday becomes table stakes tomorrow.

The Product Strategy That Emerged

Once Rooom committed to being a platform, the product strategy became clearer. They weren’t building a tool for extracting data from invoices. They were building infrastructure for document processing at scale.

This distinction shaped everything. Infrastructure needs to be flexible, reliable, and composable. Applications need to be intuitive, complete, and opinionated. Rooom chose infrastructure, which aligned with their developer-first positioning.

“Our main target audience is actually more technical,” Hans says. “So we have a low code tool which is much more similar to like if you go on AWS or if you go on Anthropic and like, you know, you fiddle around with the API.”

The platform exposed building blocks—extraction modules, validation rules, output formats—that technical teams could compose into custom solutions. Rooom handled the hard problem of document processing. Clients handled the application logic specific to their business.

The Go-to-Market Motion That Changed

Pivoting from services to platform also required rethinking go-to-market. Services companies sell through relationships and references. Platform companies need scalable distribution.

Hans found it through partnerships. “We’re building integrations with a lot of the automation vendors out there,” he explains. Instead of selling directly to end customers, Rooom integrated with the tools those customers already used.

This strategy made sense. Automation platforms already had relationships with technical teams. Rooom provided capability those platforms needed but didn’t want to build themselves. The partnership was natural—and it created distribution Rooom couldn’t have built alone.

The Lesson for Founders Stuck in Services

Hans’s pivot offers a framework for founders trapped between services and platform. The pattern is always there if you’re paying attention. Look for problems you solve repeatedly. Notice what keeps breaking across different projects. Pay attention to which parts of your custom work aren’t actually custom.

Then make the hard decision. You can’t half-pivot. Services and platform require different organizations, different economics, different mindsets. Choose one and commit completely.

For Rooom, that commitment led to a $19 million Series A and a business that scales without linear headcount growth. The platform inside their services business was always there. Hans just had to notice it—and have the courage to build it.