Goodbye Cozy

Five years ago, we founded Cozy Cloud, a company with a mission. Our goal was to give people more control over their personal data and their web services. To achieve that we created a Free and Open Source Software project: an application platform dedicated to individuals and aimed to be self-hosted by users on a machine of their own.

We diverged from existing solutions by focusing only on personal usages. On the long term, we wanted to make the personal server, the new mainstream personal device. This mission made sense to many. We were supported by a community of hundreds of contributors and thousands of active self-hosted users. In some ways, it was more than a startup project. We were driven by something larger than building a company.

Last year, after discussing strategy at a board meeting, my point of view was rejected and I was no more CTO. No need to say how painful was the ending and how hard it was for me to accept that decision. But after long discussions we found an agreement to make the situation satisfying for everyone. Now that it's done, this story is over for me and I can fully focus on the future.

To conclude these five years at Cozy Cloud, I would like to share what I learned from that experience. During that whole time, I spent building the company from scratch, I wore many hats. In this blog post, I'm going to review all the role I took and extract some tips that could be useful to you.

The Backend developer

When we started Cozy, in 2012, we were two and I was the tech guy, the developer. Most of my work was focused on building the first APIs that handle the deployment of applications, the routing of the requests, the authentication, the data management, etc. To achieve that, I learned and used Node.js. At that time, its asynchronous scheme and all the hype around made it attractive. But what convinced me was the Node package manager. It already provided a lot of utilities to build APIs quickly.

Since I worked on various use cases, from time to time, I had to dig into low level libraries. In turn, I got use to reading a lot of code from others. I got better at programming. And because of the free and open source nature of the project, my Github account grew and my contribution timeline was full.

Working at night is a great way to keep focused. So, during my insomnias (which was numerous the first year), coding was my favorite activity. I produced a lot that way. It’s unfortunate that being a late bird in this society is still not well accepted, you are often criticized because of it. But if I can put my two cents in: just ignore it! The only thing that matters is what you deliver, the matter of when you write it has no bad consequence if you deliver and can communicate efficiently with others. Building a startup is great for people like me, because people tend to judge you more on the delivery than on your waking hour.

The development, I'm most proud of is Americano, a layer above ExpressJS. The Cozy platform was based on many small web apps (a kind of micro services). Thanks to Americano, we standardized the architecture of all our modules. It really helped when we had our first hiring. It put everyone on the same page when working on the API modules. We worked much faster with it without adding much overhead during the setup of modules. A simple development helped to structure all our work.

The more the company grew, my responsibilities in significant development on the backend lessened. Towards the end of the project most of my contributions were done on experimental projects.

Additional tips:

At the beginning reuse a maximum of libraries and tools. Building an MVP, is more about assembling than writing something new.
Make it modular, so you can rewrite parts independently.
Write many tests.
Be prepared to code a lot.
Be prepared to trash things.
Keep things lightweight. You will grow and changes require agility.
Make dev environment deployment as simple as possible. So, new collaborators can start working quickly. It's even more important if you do free and open source software.
Use mostly boring technologies (with new tools, when you are in trouble, it's harder to fix things).
Don't let performance problems cripple you. Fix biggest issues as soon as you can.

Github timeline from 2012 to 2016

The Frontend developer

Before doing Cozy, I was a front-end developer. It was the field for which I had the most skills. It was a great asset to me at the beginning. I was fast to build modern UIs. But the truth is: it made me too confident. I ignored for too long that technologies in this field were evolving very fast and that I was not nurturing my frontend skills to the level where it needed to be to keep up.

Doing Single-Page-Applications five years ago was not so common. The best tool at that time was BackboneJS, a lightweight framework that does the job well for small applications. Prior to Cozy, I wrote apps with GWT. Compared to it, Backbone looked much simpler and more agile. We built great things with it but when our frontend was growing, we ran into Backbone limitations. Especially when dealing with the flow of events coming from the server and the user.

A year later (2013/2014), the reactive programming offer arrived and was much more compelling compared to the traditional MVC. At first, I wasn’t interested in React and didn't really try to understand what made it good. It was a good idea to stay focused on our technologies but the impact of React was big. It was more than a technology, it brought many discussions into the developer communities about how a frontend should be built.

The result: I was challenged a lot by my collaborators who were attracted by this architecture. Because, I didn't keep an eye on this new trend, I wasn't able to give proper answer to their questions. It ended up with a lot of hesitations about our application architecture. I lacked confidence about our choices. Looking back, following this trend closer would have allowed me to take stronger decisions. At the end, we had many different architectures on the main modules of our platform and our developers wanted to try a new technology every three months. It slowed down our shipping and brought on frustration.

The rise of ES6 didn't help. We wrote our UIs with Coffeescript. In 2012, it was more developer friendly than Javascript. But ES6 fixed most of the issues of Javascipt and Coffeescript was not compelling anymore. Which made things even messier when we started to write new modules with ES6.

Despite that, we had great applications and working software. We learned a lot and were ready to go for cleaner code. All these new possibilities were exciting and pushed us to think more about problems all together.

Additional tips:

Build a common library of components early.
Choose one framework and stick to it. Learn to deal with its limitations.
Eventually build your own library on top of it. It will be good enough for most of your use cases.
Change framework only if: it's more testable, you have time and money (and migrate iteratively).
Make it responsive early.
A CSS expert will bring a lot to your UIs.
For UIs, unit tests are better than scenario tests. The feedback loop is faster and they have a longer lifetime.

My first and last success on Hackernews for an article about frontend development.

The Sysadmin

With Lucas, our first employee and junior at the time, we built the first version of our hosting infrastructure. It was a domain almost new to me, I’ve only had experiences with personal hosting. At the beginning, it was hard to do things properly. I had to learn container management (with Openvz) and configuration management (Saltstack). Thanks to these great technologies (and some help from Majerti), we succeeded in building something that worked and could host many Cozy instances.

But hosting requires a lot of skills. So, after our first fund raising, we decided to recruit an expert to work on it. That's when Nicolas joined us. He was our first senior hiring. It was the first time I delegated fully something important to someone else. This was also new territory for me, we were under a lot of stress and there are times that I wished I had behaved better. Thankfully, Nicolas was very professional and made things smoother. Finally, the transition was properly done and we did great job together.

At some point, hosting requires in-house software for proper monitoring and management. Fortunately, ops are ok to be used to command line tools. So building UIs are simpler, it gets more complex when the marketing and support teams needs to know the states of the users (like inactive users or broken machines).

By the time I left, we were operating more than 2 000 containers on our infrastructure. After a talk from Nicolas about what we do, we were approached by Intel Capital.

Additional tips:

Rely on PaaS / DBaaS hosting at the beginning if you can. It will be much simpler to ensure quality.
Don't be afraid to make an average version at the beginning. But once it's running and growing, hire an experienced System Administrator.
Monitor as much as you can.
Define processes to fix problems quickly.
The pure Kanban method is better suited for running production than the SCRUM method.

Nicolas giving a talk at OVH summit (photo by Brendan).

The Product Manager

The more Cozy Cloud grew, the more I was involved in this role. After our first fundraising, our investors suggested to hire a specialist in this field. But in France, there are not many people who are able to handle this position and our idea of what is product management was not clear.

So, to make sure that we hire the best person, I studied product management and strategy as much as I could. I understood we are faced with a lot of room for improvement in this field. Cozy required more packaging and simplification. I also noticed how Cozy had a strong disruptive potential. Most importantly, I learned how to reach big markets by conquering small ones and the importance of offers renewal.

I also understood that we needed more formality in how we add features to the product. The choice of our priorities was too messy, it required more objectivity, more metrics and less gut feeling. So, I moved two employees to the PM role. They were part of our early employees and knows the vision well. They had more time to collect information and to synthesize them properly.

They achieved great results. Together, we built a map of the current state of the product. Then we organized our user feedback and prioritize our features. We had a clear road map and aligned the whole team efficiently with it.

Tips:

Be opinionated.
Look for a population of users that you can afford at your level of scale.
Measure and experiment before going too far in a direction.
Don't be ambitious with your features.
Be ambitious when you talk about the vision.
Vision is long term, roadmap is short term, don't mix them.
Small iterative changes are less risky and more accurate.

Advanced prototyping of data syncing through a small box at home (ok I forgot to plug the box on the picture ;)).

The Engineering Manager

During the last years at Cozy, it was my primary role. It was something new to me and I wanted to be good at it. So, I met several CTOs from other companies. I wanted to get advice on how to handle things. I was satisfied by this experience; every meeting was very informative. Unfortunately, I couldn’t continue because I got overwhelmed by my day-to-day responsibilities and decided to put a halt in meeting other CTOs for that time being.

Now if you’re curious on how we worked: we followed classic agile methods. At first, I made it very light and the more engineers we had, the more I added rules from the full agile methodology. Being iterative with your methodology is important too, things change fast and you team organization should be flexible enough to deal with that.

For our infrastructure team, we chosed to use the Kanban method instead of SCRUM. It worked better for our production environment. Hosting is full of surprises.

Overall, agile is great to keep everyone on the same page and ship on a regular basis. It's the way to go to build a new company.

Another thing to point out is that we were a remote team. To make sure everything ran well, we had a strict schedule of our daily and retrospective meeting. Having a good discipline for this is essential to put everyone synchronized and keep the team motivated. Better, it gives good communication habits: everyone know when it is time to ask for something or to share a news.

SCRUM and Kanban are good to handle process; however, it doesn't tell you how to behave properly. To deal with that, I used a framework called intent-based leadership. It's a framework I learned from the book Turn Your ship around. The principle is that you let people do their job their own way. But you keep on getting information and ask them how they see the whole situation. From that data, you have a 360° view, you can take better decision and provide the main direction. In turn this also allows everyone to feel recognition on what they do and to be better informed.

When it comes to hiring, we didn’t have much difficulties. We had a strong mission, worked with good practices and were present at tech events. So, we always had great candidates. The hardest thing was to choose among these talented people.

As a founder, my role was wider than a traditional CTO one. It was a challenge that I strive for. Retrospectively (and thanks to a discussion with Stéphane Bagnier), making a clear distinction between the voice of the CTO and the voice of the founder would have improved my communication towards other stakeholders in the company.

Finally, I would say that these aspects require a lot of attention. Making sure that everyone is on the same page and is going well requires dedication. You will also need precision to adjust things before it heads south.

Additional tips:

Be respectful.
Listen, listen a lot.
Learn from others.
Provide advice to those who are ready to hear them.
Don't let strong opinions overcome yours.
You will frustrate people, accept it.
You will make wrong choices, accept it.
A poor decision is sometimes better than no decision.
Show that you work with the best ethics and you will attract good developers.
Ask for feedback.
Make people accountable.
Encourage your employees to do talks, technological watch and trainings.
Meet CTO from other companies and share your experiences.

A day at Mozilla with the team (photo by M4dz)

The Community Manager

Through, Github, Twitter and our forum I was involved in community relation. to build an alternative to major cloud services, a strong community. Morevoer, as a founder, it was mandatory to hear the voice of our users and talk directly to them. Doing community-related actions was the opportunity for me to listen to the problems faced by our users and supporters (and solve them!).

To delve in further, I made the first set up of our translation tool. I made and distributed goodies (tee-shirts, stickers and mugs). Then I initiated our meetups, we started with three people in a bar in Paris and ended with more than 60 people in a conference room. Tristan relayed me on that part but I kept my involvement until the end. We even saw meetups popped in other French cities too.

Meeting the community was very energizing: we always had a good time. It mattered a lot for the team to meet users. It kept them motivated.
It was good for the project too. It developed the traction and rewarded the people involved in the FOSS project. It's one of the best thing we did for our community.

Additional tips:

Give space for users to meet and interact.
Show people they can be part of a group by using your product.
Make your project contribution friendly.
Have a mascot and create goodies from it.
Say thank you to every people spending time on the project.
Enjoy every moment spent with the community.

Meetups were the opportunity to drink good Belgian beers too! (photo by M4dz)

The Support Engineer

This department is the human voice of the company. At the beginning, I was the only one doing support. I spent a lot of time on reading what people said. By doing support, I learned how to answer to angry users and be grateful to people who are sending good feedback to us.

Then, we had to get organized with the ops team to fix serious problem as fast as possible. So, it required a full-time employee. I delegated support fully to Clochix, a member of the team. He handled the role very professionally. By the time I left, our support was recognized as one of our key advantage and Clochix was one of the main figure of the company.

Additional tips:

Answer quickly to support request.
Don't take bad feedback personally.
When someone is mad at you, agree with him/her on the situation at hand and see how you can help. If the person has a passionate reaction towards the product and its problems it's a good indication that this person cares about the product.
On the other hand, learn to recognize trolls and don't feed them.

Some topics were hot on the forum.

The Designer

For an open-source project, we were considered as an application with a good UI design. After our first fund-raising, we hired a senior front-end developer. The improvements he added to the platform were great. Therefore, we decided to go further by hiring a full-time designer. That was one of our best move. He improved the whole user experience of Cozy and clearly brought our product to the next level.

Prior to that, I was the main designer. I had to deal with every aspect from branding to application UI. To build the main materials, we hired a freelance designer. Then, we worked iteratively and improved our UIs with feedback from our users. The result was not fantastic but good enough to convince people to use it. To not handle everything, I also taught the basics of design to our developers. Training is a great way to not spend too much time fixing other’s mistakes.

Additional tips:

Keep your design consistent: chose one font and two/three colors, then stick to it.
Reuse icons from websites.
Use white background.
Reuse colors from app you like.
Hire a freelance designer for important stuff.
When you have a meaningful product, budget, and no designer in the founding team, hire a designer as a full-time employee.

My last big contribution before our designer took the relay (icons were made by freelancers)

The Marketer

As a founder, I was always concerned by the adoption and our metrics in general. So, on the little time that was left to me, I worked on improving our traction. I tweeted on a regular basis, did a little bit of press relation (tech platforms like Wired and numerous small blogs), took advantage of link factories (HackerNews, Reddit), improved our website, added our stack as prebuilt image of hosting provider catalogs and make sure we were mentioned in the right places and some more.

I did my best to keep our branding consistent everywhere. I made sure that our logo was properly displayed. I considered it as the main tool of our propaganda. I wanted everyone reminded us through our logo. Stickers helped a lot for that.

Experiencing traction and growth is addictive, I always wanted more. Not sure it was a sane thing, but at least I had a clear goal every morning when I arrived in front of my computer. During 18 months, every six months, we achieved a 100% growth of our application downloads. Which means that more and more people were trying our platform.

Additional tips :

Identify one communication channel and stick to it until you can afford using a new one.
Traction is close to useless without retention.
Keep your branding simple but make it consistent and good (one logo, one tagline everywhere is ok).
Measure the impact of your actions.
If you chose to do content marketing, build a factory to produce content on a regular basis and make sure that everyone knows you published something.

Happy user seeing our platform listed as default image for OVH VPS.

The Speaker

Building Cozy was the opportunity to participate to many conferences as a speaker. At DotJS, I even talked in front of 900 people! Talking in front of many people is a good exercise to build a clear and compelling explanation.
Now, I don't feel much stress before doing a talk and I'm able to give a well-defined one. I acknowledge that I still have many rooms for improvements for example to have a less monotonous tone, but my skills in this field got better during my startup journey.

Additional tips :

One idea per slide or no slide at all.
Don't include too complex things or try divide them in smaller parts.
Tell a story to make things easier to digest.
Live coding requires more repetition.
Allow people ask questions during the talk but bring the audience back to the talk quickly.
Have a remote to move slides.
Have screen adapters.
Bring PDF version of your slides.
Don't expect to have a wifi connection.
Or don't use slide at all.
Read this.

Me speaking at DotJS

The Entrepreneur

I'm not sure I deserved this hat. I was CTO and we have never sold anything except services. Selling a product early was something that mattered a great deal for me, because making revenue would have make us more independent and would have brought more fuel to our growth. But the board was more attracted by a strategy that involved a lot of R&D. One of the goal was to build complex solutions that could satisfy big companies. It's a kind of strategy mentioned by Pieter Thiel in his book Zero to One. So it's probably a good thing but it made me uncomfortable. That's why I pointed the fact we were doing no repeatable profit and that's something we needed to address. The board choosed to not follow me.
Strategies based on big R&Ds and partnerships were not interesting for me, I should have accepted it earlier.

On the positive part, we had users, we caught the interest of many big companies and we raised more than $5M. With the first fund raising, we attracted many talents (23 people by the time I left). We had the most evolved personal platform and built a strong community. We received exposure in many places and were approached by many. Sadly, I will not be able to learn from spending our money from the A series.

During the journey, even if I was considered the tech guy, my job changed a lot. I had to learn a lot on my own. This is important to not become a problem for the project. I used to read blog posts to discover new fields. But reading (tons of) books and talking with experts were the two most efficient ways for me to reach quickly a decent level in a discipline. Books are often the result of years of practice and thinking by the authors. They allow you to get in their head for a few hours. It would be sad to miss that. But being good at something requires practice, so don't expect to do great quickly. The most important thing is that you understand the theory. It will allow you to chose the right person for the job to replace you when you can afford it.

And the more you are, the more you need process to keep everyone synchronized. For that we had a fully remote team and were organized in a horizontal manner. On internet, it looks almost common but when you were not connected, it impressed many people. Remote and collaborative work was part of our culture. Especially because we did an open source product. Sometimes, we felt guilty with the remote aspect and was not sure it was the right way to get organized. But I think it was a mistake. We should have assume it more and be proud of it.

Agile and remote worked great together, it made us super productive and allowed us to hire everywhere in France instead of getting limited to Paris. It pushed us to a have lot of discipline in our internal communication and made us more efficient. With our horizontal structure, people felt respected and kept on telling us how much they enjoyed working for us.

The way we worked was one of thing I'm the most satisfied of. Building that kind of organization was one of the main reason I started a company. I'm glad we succeeded in doing it.

Additional tips:

For hiring and fund raising, make your company attractive. Everything will be much simpler.
Networking, UI design, branding, user acquisition are catalysers but they are close to useless if you don't have a proper market/fit (and a good retention).
So focus first on market / fit and user experience.
Make you dispensable, to look for new opportunities or new growth vectors, it will require time. Your organisation should be able to live while you are not working on the day-to-day.
Try to do one thing at a time until you feel confident about replacing yourself on the subject. But understand that you are doing cycles and will have to come back on this subject at some point.
Define frameworks, stick to it. Then redefine them every trimester or semester.
Celebrate when you can, enjoy. You don't know when and how it will end.
Have a close to equal share repartition, you will work for 10 years on this project, what you bring before it does not count compare to what you will do in the future.
Despite the coolness of the startup ecosystem, it's still business. So when you talk about money, think accordingly.
Nurture a good relationship with your investors, even if you are not the business guy.
Sell something as early as possible.
Take significant vacation.

Press anouncement for our first fund raising.

The Dreamer

The more I was involved in Cozy, the more I thought that we were going to have a big impact on the world. Bringing back web services and data at the user level put him in charge of its digital life. It opens the door of more trust in technology, better interaction of personal tools and more speed of communications and of course it brings also more freedom. This alternative to proprietary cloud services would have been a big relief for many people. Last but not least, by providing largely deployed distributed applications, it will have outperformed centralized architecture in many fields like IoT, data management, quantified self and personal assistants.

On the personal level, I wanted to earn recognition from my peers as a developer, a CTO and an entrepreneur. But, nothing of that happened. And seeing your dreams ruined is the hardest thing to accept when you fail. In some way it should not be a big deal, every project is an experimentation and most of them fail. But it's still hard to swallow.

There is no simple solution to manage failure. The only thing I can recommend if you face a similar situation is to recover by taking a big break (in a sunny country if you can afford it). Then look for what is left and build upon it as soon as you can.

Tips:

Let your dream drives you when you need to dare something that may sound crazy at first.
Let your dreams gives you strength when you need courage.
Sharing your dream is your best tool to convince people to join you.
Don't let it blind you when you are in the wrong direction.

Years ago, Tommy Rombouts designed a box to make the personal server stylish. When I saw it I thought: how awesome it would be if everyone had his personal cloud at home?

Final words

The overall experience was priceless. I met many people. I got new friends, worked with talented team mates and learned a lot. I experienced the joy to see people believe in a project I initiated. I got much support and it was thrilling. I made promises. I believed in them and made other believed in them. But I failed to fulfill that promises. That's why, to all people who supported us, I apologize.

Building alternative to major cloud solutions is still an unsolved problem, but I'm confident. Recently we had another great software on the social aspect with Mastodon. Owncloud got a second life through Nextcloud and the list of self-hosted apps keep growing. With more initiative like this, we should have a compelling alternative available soon.

People asked me if I want to fork the project. It's not needed. The Node.js version of Cozy is going to be abandoned. So the best thing is probably to maintain it and to keep it alive. It's still a good software result of many feedback that makes life of his users easier. It would be great to see it getting his own way as a non-profit community project. If people are interested in this idea contact me, we'll see what we can do.

About the new version of Cozy, it is aimed at improving the customer experience with big companies customer accounts. It is good, it will sound better for mainstream users and it will take advantage of what we learned from the previous version. But I don't feel like I'm the target user anymore, so I will not use it. Despite this, I'm pretty sure that the Cozy team will make a great product.

To finish, I would like to say thank you very much to everyone who get involved in the project, to the Cozy Team, especially to the first employees who trusted us early in the process. Thanks to Mozilla and OVH who helped us all along the way. Thanks to all the persons who supported us. Once again we saw that software is people. It's you who made the project exciting and meaningful.

I send a special personal thanks to those who provided me with guidance at a personal level. Without you, I would have probably given up. Thank you Pierre, Diana, Fabrice, Manu, Greg, Alex, Isabelle, Florence, Ronan, Misc, Haikel, Aurélien, Florent G., Florent T. and Khuram.