Before Kombo

Alex, Fabi, Niklas, and I met at university in Berlin. We all had already been coding for nearly a decade as a hobby. We wanted to build something big and real together. We dropped out of our studies and locked ourselves into the office, living on €500 a month and working six days a week. There was not a lot of other stuff we could do because it was COVID lockdown.

Our initial bet was to start a service-heavy business scraping mobile apps and analyzing their data for customers to learn about the industry and build a product out of the technology. It made a few hundred thousand euros a year but we were never able to turn it into a scalable product. We killed the agency and applied to YC mid-pivot, and although our ideas were weak and the interview chaotic, the partners still took us in, likely betting on the team more than our ideas.

Earlier, we had already wasted months on bad startups, sticking with poor ideas for years. The main lesson: focus on the most important thing: find and solve an important problem.

Pivot as a Numbers Game

When we pivoted away from the service-heavy business, we used Airbyte’s mental model on pivoting as a new approach. They had written these two blog posts that really guided us a lot: How We Pivoted 3 times In The 1st Month of YC | Airbyte and The Hard Things about Pivoting | Airbyte.

A core idea was to pivot as fast as possible. We came up with a strict system: Every new idea got at most two days of initial investment. On the first day we would research the space, look at competitors, and try to understand how existing solutions worked. By the afternoon we were already sourcing around a hundred relevant people to contact. On the second day we sent one hundred personalized emails to ask for discovery and validate our solution with them (we always pretended we had something already). All in one day, not spread over weeks. That pace forced us to move with urgency.

If nobody replied, that was enough of a signal to kill the idea immediately. If some people booked calls, that was at least weak validation that the space and problem was not completely BS. It meant the problem sounded interesting enough for them to talk about.

In the end, the only real signal is money. In the beginning we sometimes lost weeks by not bringing up the question of money soon enough. Eventually we forced ourselves to always ask at the end of the first call whether they’d be willing to pay a few thousand euros per year for our solution. If the answers were vague or negative, we killed the idea. For us it was a numbers game: every idea got a hundred emails, and if there wasn’t traction, we moved on.

Being in YC was a great addition for this as well. Participating in the batch intensives both your focus and urgency. It forces your to not fuck around.

Siren Song of Developer Tooling

Because we didn’t have any real industry experience, the ideas we looked at were all over the place. Some weren’t really B2B, some weren’t the type of problems you’d build a deep tech company around. Even if there seemed to be an opportunity on the surface, they didn’t stick and we didn’t enjoy working on them. We always ended up drifting back to developer problems. We had been building software for ten years already, so this was the space we understood best. That bias was both good and bad. It was good because we could understand technical pain quickly and execute fast. It was bad because developer tools are one of the most crowded markets you can possibly choose.

We also realized an important distinction: build-time tools tend to churn, while runtime products naturally stick. The reason is simple. With runtime products, you are operating the system for the customer — you’re running the servers for them and solving a problem continuously. That’s already worth a lot. It justifies higher revenue, and on top of the costs you’re incurring, you can charge a big markup for the value delivered. That makes runtime products much stickier and much easier to monetize. In contrast, build-time tools are used sporadically, often only during specific phases of development. It’s much harder to charge significant amounts for them. I saw this pattern across other developer tooling companies too: the build-time tools had trouble scaling the company, while the runtime products naturally entrenched themselves.

Every Real Problem Is Old

Another big learning was that companies don’t really have “new” problems. Unless there’s a big environmental shift (regulatory, war, or disease), almost every problem already has people trying to solve it. Initially, we wasted time chasing things that weren’t solved yet, thinking that meant opportunity. In reality, those problems usually weren’t real, and companies just didn’t care. The safer bet is to solve an existing problem with a new technology. Many of the so-called “unsolved” problems are really just tarpit ideas — the kind everybody keeps thinking about, but nobody is solving because they don’t matter enough. I think these ideas are typical for people coming straight out of university and looking for something to solve.

The problem we are solving with Kombo today is a decades old problem: make your SaaS solutions talk to each other. There are generations of old technologies that companies used to solve this problem already. Unified APIs were a disruptive new technology that was made big by Plaid.

Competition is Good

Competition also turned out to be something we misunderstood. At first we thought that if there was already competition, they would own the market and we wouldn’t stand a chance. That was wrong. Competition is actually good. It proves there’s a real problem and a budget. No competition, or only tiny stagnant players that never grew, is a bad sign. And even when competitors exist, a small founding team can still beat them by being closer to customers, providing better support, and iterating faster.

I saw this very clearly later at Kombo: when we started there were already Merge and Finch in the US, both a bit older than us. But with a lot of focus, better support, and faster execution, we built the better product and became the global winner in HR and ATS integrations.

Worth noting is that the existence of competition does not prove the problem is real and worth building a solution for. Over the years we worked on many ideas with VC funded companies as competition. Looking at their websites years later, almost all of them went out of business or pivoted to something else.

Startups Die of Missing Morale

Living through Pivot Hell was emotionally brutal. It felt like being stuck in a dry valley with no horizon. We’d get excited about ideas, dive in for a few days, then kill them and start over. That cycle repeated again and again. It was draining because we weren’t shipping, we weren’t earning, and we were constantly tearing down our own work.

I’m that kind of person who takes a lot of self-worth out of producing valuable work. Find something that gives you joy outside of work during these times. I went partying a lot on the weekends, but for others its sports, friends, or whatever. Going through pivot hell is an endurance race. Most companies don’t die during this time because they run out of money, but out of morale.

Burn a customer instead of yourself

I realized that time is the only resource that matters when you’re in Pivot Hell. You don’t make money, and nothing gives you gratification. You can only do it for so long without running out of money or morale.

We optimized a lot for speed. We sold before we built and did everything as cheaply as possible. I built the first landing page for Kombo in a single afternoon with a free website builder. After two weeks, we signed two LOIs, and one of them already converted into the first paying customer. That was more validation than we had ever seen with any other idea, which is why we stuck around.

We then spent two more weeks coding, launching the first version, and returning to selling. We closed about a hundred thousand in yearly revenue just before demo day. The product at that point was buggy, unfinished, and obviously early. However, in B2B adoption, it always takes a while. There’s a natural lag between signing and customers actually deploying the product, and we used that time to keep building after we had already sold.

I’ve heard many people fear being unable to deliver after selling. Ultimately, it doesn’t matter if you burn one customer because of a bad product. You shouldn’t enter a market where your success relies on this first customer. Having the conviction that people have a problem they are willing to pay for to solve it is much more valuable than a first deal during this time.

That rhythm of selling first and building later was what finally got us out of Pivot Hell.