Struggle in Freelancing to Build an Ambitious Product
“It’s always day one” (Jeff Bezos)
Survive
In 2017, Arthur and I started building a product around a similar problem we both experienced multiple times. Indeed, for years we accumulated plenty of articles, notes, tweets, and videos about a number of different subjects but hadn’t figured out a way to organize this content properly. We looked for a product that could help us and tried many of them, but we couldn’t find the right one.
We dreamed of a personal Google. A place where the content organization was not a problem, a place where the content organized itself and where we could get what we were looking for in a matter of milliseconds. That’s the product we created. We worked on it for more than a year, released several versions, and onboarded hundreds of beta testers.
Many of our testers complained about the lack of integrations. They were annoyed to be unable to import all of their existing content. After having interviewed each of them, we had a list of thirty possible integrations. We wanted to build all of them. After we started working on it, we quickly realized that it would be about four months of full-time work in the best-case scenario. So, we looked for a product to make the integrations quickly but couldn’t find any.
At the same time, we were frustrated and fascinated. We were frustrated because we had less than four months of cash saved up. We were fascinated because we were sure that many ambitious product builders would experience the same frustration.
After several days of reflection, we decided to build a platform that would turn integration building for developers from complicated and tedious to enjoyable and straightforward. However, we were nearly bankrupt and didn’t have strong knowledge about APIs. Thinking about it, we quickly realized that we would solve these two problems by building integrations for SaaS companies as freelancers. And that’s what we did.
We started integrations.love by just building integrations for SaaS businesses in France. We didn’t get rich by doing it, we spent much time solving a number of really boring micro problems about APIs, but we stayed at flows financially and learned a lot about the problem we wanted to solve.
Learn
The first request we had was about the worst API ever. This API wasn’t documented anywhere. The developers tried to figure out how it worked, and they regularly complained about the API on Stack Overflow. We spent days on tests to figure it out, days to build the requests, and more days to have a production-ready version.
Retrospectively we were lucky to get such a request as a first mission. It exposed us early to the reality of the challenge. Even if APIs respect standards, they all respect standards differently, and sometimes they just don’t respect any standards.
We also got other jobs. Each time we spent much time with the client to understand their business logic. We also wanted to know why they wanted to build the integration and why they didn’t make it themselves, which was the expected output and the business model around it. We started to figure out a few patterns along the way. It was an intense period of learning.
We also got a lot of unsuccessful meetings. These meetings were maybe as important as the successful ones. We learned a lot about our target’s psychology, about the way they were building their product roadmap, and about their views on integrations.
Looking back, we realize that we were doing what we were supposed to do: experiment with our client’s problems as much as possible to understand them deeply. Solving real problems and repeating the process has been our daily life for months.
It has been a fascinating period. Of course, we struggled to survive, but it sped up our learning curve in some way. We were forced to focus our attention on the most urgent problems we had to solve and just ignored everything else. Going through this process, we earned the needed money, time, and knowledge to start building our platform effectively.
Build
We started thinking about the platform from day one. We used a simple mental model to build it. Every problem we solved by code could be solved by the platform one day. The idea behind this model was quite simple. Indeed, each issue we faced, even the tiny ones, were problems faced by our potential customers. As we wanted to remove all the complexity of integration building, the platform had to handle all of these problems elegantly.
In a few months, we had the first basic version of the platform. We viewed this version more as a starting point for iterations and tests than a minimal viable product. But something important changed with it. We stopped accepting freelance missions when we weren’t able to use it to build and execute the integrations. That could seem trivial, but it meant that we didn’t solve a problem twice anymore. Plus, each issue we solved improved the platform’s value.
One year after we started to work on the platform, we signed an excellent contract with a company that needed a complex integration to close a big deal. It was perfect timing for us. We thought that the product was ready to be used by real people. We prototyped their integration on the platform and onboarded the team. We were full of hopes, but the experience had been tormenting for them.
We made a significant error of judgment, we thought that generous support from us would have compensated for the lack of documentation, but actually, it didn’t. Too many points in the product were unclear, counterintuitive, or just buggy. Despite our efforts, building integrations remained too complicated for real people. They churned a few months later, and we’ve had a great lesson: Do not hurry; we are in a long term game.
In the following months, we made the product more user-friendly, wrote down documentation, and onboarded new paying teams. However, integration building remained too complicated. We had accumulated a lot of feedback and observations about what went wrong, but we were limited by our early technical choices for solving the most important ones.
From this point, we decided to rebuild the product from scratch by merely using what we learned along the way to build one that was ten times better. That’s what we are currently doing. We can do it because we have experienced many of the problems we wanted to solve, and we’ve got the needed money from doing so. Freelancing has not been a dead-end for us, just the starting point of something really ambitious. It is definitely always day one!
We’re going to document our Journey on Twitter, you can follow me there if you want to keep updated about it.
