Hi Jan! What's your background, and what are you currently working on?

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.

‍

What was Flux about? How did you come up with the idea?

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.

‍

How did you build Flux?

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.

Why did Flux fail?

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:

‍

• Looking for investment too early/ at all:

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.

‍

• Bad cofounder fit:

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.

‍

• Over-engineering:

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.

     3. Too early adoption of micro-services with wrong service boundaries: I tried to use whatever developer resources I could get my hands on and allowed them to use languages they thought were great as long as I also found them interesting and fitting. This lead to a mixture of Erlang, Go, Ruby and JavaScript that became extremely hard to support especially as developers with different knowledge joined and left. In retrospect, I should just have completely bought into the node.js wave, but at the time node.js was nowhere near the solid platform it is today and as we over-estimated the short-term funding and growth possibilities: we just thought that investing in reliable and scalable services would pay of sooner than it would have and that the language zoo would be no problem as the team grew bigger.

     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.

‍

• Bad luck on timing:

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.

‍

• Focusing on consumers instead of businesses for too long:

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.

‍

• What finally killed us:

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.

Which were your investments? Did you achieve some revenue? Did you lose any money?

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.

What did you learn?

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.

What's your advice for someone who is just starting?

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.

Which entrepreneur book would you recommend?

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.

‍

Where can we go to learn more?

I am not publishing much at the moment, but if there is any news, I will most likely post it on Twitter and GitHub.