You will learn how important it is not to overengineer your startup, and find a co-founder that can counteract your disadvantages.
Sponsor Failory interviews and get your business & product in front of +20,000 CEOs, startup founders, entrepreneurs, developers and marketers every month.
Hi! I am the founder and CTO of Flux, which was a modular multi-messaging client. I studied a bit of physics and philosophy before, but I am mainly a self-taught full stack developer. Right now, I am in the middle of open sourcing all software that we built and using it as a basis for consulting and freelancing for companies that need a messaging platform. I am really grateful to all our investors that allowed me to do this and I am confident that somehow something new and bigger will evolve out of this unique situation.
The main idea is quite old and evolved out of discussions with friends at university. The main pain point we had at that time was that Facebook just entered the German market and we experienced firsthand what it means to have all your messages and friends stuck in the data silo of studiVZ, which was the German copycat that was used before Facebook. The basis of all product iterations was always that we tried to build something that lets you own your data but still take part in mainstream social media with normal non-nerdy friends. First prototypes were before diaspora but similar federated social networks. We quickly learned that support for all data types (images, events etc.) was too much, so we focused on the most important one: messages. The second learning that led to the product idea was that replacing the status quo was impossible so we focused on building a professional messaging product that used existing messaging channels like Facebook and email.
We did never enter a growth phase and failed already in private beta. But we had a few thousands of users on the waiting list. We mainly got them through giving talks and public pitches as well as exposure from our accelerator StartupBootcampBerlin.
Try Pull Reminders, a Slack bot that automatically reminds your team about open GitHub pull requests. Join 400+ companies like Pivotal, Instacart, and Trivago that are using Pull Reminders to review and release code faster.
A combination of many issues, probably any one of them would have been enough for a failure, so I am still somewhat proud of what we achieved. This is my overview in no specific order:
The product we tried to build was just not that interesting to investors, I see why with my knowledge now, but at the time we thought it was just about not trying hard enough. In retrospect, it was stupid to look for bigger investors at all, at least in Berlin. Had we just tried to sell consulting, services and custom solutions and building the product along the way instead of the wasted VC time we would have gotten much further. The wrong impression I had was based on reading mainly US-based blogs as well as listening too much to people from the Berlin startup world that gave advice on how they thought or wished things would be instead of the actual experience of success in the current world.
Me and my business cofounder were extremely opposite characters and at times there was a great synergy but more and more often this lead to a lot of friction. Also, co-founders should probably know each other for more than a year before, but we just met for the venture. Lastly, I highly overestimated the available funding in Berlin for this extremely early stage and kind of product and so assumed that a business person who is good with people had more to do than was the case. I naively thought he could just go and sell a prototype to a VC and then build up the office and hire the people as well as do finance and contracts when in reality all we needed was people to work on the product until we could show traction.
I am responsible for over-engineering a few aspects of flux. I changed a lot since then, to not make the same mistakes again. But reading about extreme programming and MVP is one thing but I don’t think I was able to really “feel” what it means without having gone through the situation. The following are the main over-engineering mistakes:
1. Overestimating the convergence/ availability of REST APIs: I thought all companies will publish a REST API with converging concepts for paging, endpoint structure, authentication, references and pretty open usage restrictions. Therefore, we built a DSL for connecting and consuming REST endpoints. In Erlang. We could just have built the first connectors manually and then at a much later stage still develop a DSL and automate the process if it would have made sense then. This was also a big problem because investors asked us about ‘secret sauce’ all the time, so the technology for connector building seemed really important to us. When in reality the problem was we wanted to impress investors in the first place.
2. Over/Under engineering Client Model: I did not know about observables and Rx, maybe they did not even exist then, I’m not sure. The point is the same however: the view model for flux became very complex and depended on multiple asynchronous processes and a locking system to generate it consistently grew hard to manage. Today I would not have half the headaches from then because of RxJS or similar tools.
4. Technical idealism at the wrong place: I am and always was a CouchDB fanboy. But at the time the concept of CouchApp was also on the horizon and I was so much into the vision of distributed, independent and self-contained web applications, that I tried to make the whole architecture work in such a future. This future never happened and I could have spent a lot of the time working on actual product features with immediate impact.
When we started, Twitter’s API was still hugely unregulated and Facebook and Google had an XMPP API for messaging and saw it mainly as a relatively unimportant extra for their main products. But then messaging was the new big thing and they changed to a more closed and even more walled garden strategy. This was before business messaging accounts were on their focus, so we did not have the old API but the new APIs (e.g. Facebooks pages messaging) were not available yet. Needless to say, this was a small disaster for a startup with very limited resources. Luckily, we supported emails as a channel from day one so we could focus on email use cases. Maybe email support would have been on the over-engineering list too, if it did not allow us to build new iterations in this difficult time. Good email support is a huge pain to build, but once you have it, it’s so powerful, that I do not regret a single sleepless night building it.
Building a product for consumers instead of businesses requires a very different mindset. After it became clear consumers and prosumers would not be a big enough market it took us too long to start focusing on businesses, mainly due to the different cultures.
Contract Negotiations with a big German business: When we finally managed to make the switch we were already very low on runtime. It was clear we could just try this time. One of our investors gave us one of their lawyers but the contracts were just an endless rabbit hole. When we finally found a somewhat acceptable basis, the big company had a restructuring and the contact person changed, we had zero runtime left and instead of being able to start the cooperation we had a new contract version in the mail that gave them complete exclusivity on so much of the project that we could never have used the software with a different client. That was the end.
We raised a small angel round of ~ 70K € and burned through ~ 70K € of private savings for living costs for me and my co-founder. After giving up, just keeping alive the company entity and getting everything to a happy ending cost me another 15K. Our first business deal never happened and we never had revenue, so all this money could be seen as ‘lost’. On the other hand, the learnings and time we had were incredible so for me at least it was totally worth it.
A practical guide on how to become a Viking and beat every problem you will face when building a side project.Download Now
In addition to all the learnings from mistakes I already talked about: I learned a lot about my weaknesses and people. Lastly, I hugely improved as a developer, architect, and CTO. This personal development is hard for me to put into words, it’s just too much, and it is hard to tell what is a result of growing up and what is directly connected to the startup experiences. Just so much: I am not naturally good at implanting my vision into other people and also, I am not good at letting go and accepting half-baked solutions with long-term risks when there is not enough time.
I don’t want to give advice; the world is full of un- or semi-successful entrepreneurs happily giving advice to anyone and even those who were successful are full of survivorship bias and most advice is bullshit anyways. If someone has a question I am always happy to answer as honest as I possibly can.
I think books about entrepreneurship or technology are overrated. I read abstracts about all important concepts and go into slightly more depth for things I find relevant or interesting, but reading or writing a whole book instead of “doing” just feels fundamentally wrong.
We’re always digging for more failure stories like Flux. Sign up for our newsletter to keep updated on the latest additions.