Qovery’s journey towards product-market fit together with their community

An interview with Romaric Philogène, co-founder at Qovery

Hi community friends! 👋 We’re back again with another awesome interview. This time we had the opportunity to talk to Romaric Philogène, co-founder and CEO at Qovery.

Romaric shares how they first used the input of many experienced developers to determine what to build, how they find and recruit ambassadors for their community, how open-sourcing part of their product benefits both the community and the company, and a lot more! 🚀

Let’s dive in, and don’t forget to hit the subscribe button (if you haven’t) to follow along on the next issues! 👇

P.S. The Build With Users Jam is back next week for the first event in 2021! 🔥 It's a small-size online meetup for dev advocates & community managers where we help each other to become more effective in building our user communities and driving adoption. This time it’s all about Content Planning & Prioritization. Check this RSVP page to learn more!


About Qovery and Romaric

While the possibilities of cloud platforms continue to increase, so does the complexity of utilizing it to its full potential. Qovery aims to be the simplest way to deploy your full-stack applications to the cloud. Starting out during the Techstars accelerator program in 2019, the team launched their first version in January 2020. Since then both the community and the product have grown rapidly, which resulted in raising a $1M pre-seed round with some well-known angel investors.

Romaric Philogène is co-founder and CEO of Qovery. He is an entrepreneur with an engineering background and has worked at several companies before starting his own startup. He likes to connect with other people and share experiences. That’s why he is involved with the community building aspect of the company. In addition, he enjoys teaching computer science classes online.

At what stage of the company did you start an online community and why?

We’ve been running a community ever since the beginning of Qovery. It’s really part of our DNA, both for the company and the founders. Before we started Qovery, we created one of the biggest motorbiker communities in Europe with approximately 85,000 members. So we already knew how much value a community can bring to the product and to its members.

Our goal is to provide the best developer experience possible. And to get to that level, we needed to have their feedback right from the start.

For Qovery in particular we want to involve our target audience, the developers, as much as possible. We encourage them to participate in the community and also contribute to the product. Our goal is to provide the best developer experience possible. And to get to that level, we needed to have their feedback right from the start. That’s why we’ve been actively reaching out to developers all the time, even before there actually was a product.

In the very early days of Qovery, we participated in the Techstars accelerator program in Paris. This is an intensive three-month program, during which startups are mentored and are given access to an extensive network of partners, investors, and alumni. We took advantage of this opportunity to talk to a lot of experienced developers before we started building anything. This helped us to really understand how they’re working and learn more about the challenges they encounter in their daily work.

Once we were certain that we had a good grasp of the underlying issues that we wanted to solve, we started building the product. It only took us about a month to build the minimum viable product (MVP). This time was spent fully on development, because we had already collected enough feedback beforehand.

After that month of building the product, we launched it in January 2020. Our community consisted of about 50 developers at the time, all using our product. They were the people whom we talked to earlier on. By working closely with them and getting them involved in the challenges we were facing, they became part of our journey as well.

What platform(s) do you use to run your online community? What are the pros and cons?

We started our community in Slack, because many people are already familiar with that. However, we quickly realized that it had some significant drawbacks for us. Slack was never built with communities in mind, which is noticeable in several ways. For instance, it became too complex to manage for us. We also didn’t like switching between our internal Slack workspace and the community workspace all the time. Furthermore, the restricted message history is also annoying, as questions and answers get lost over time. This can be solved by upgrading to a paid account of course, but with Slack’s pricing model that’s not really viable for large-scale communities.

We feel that voice chat helps us to create a good and personal connection with community members. This is vital for successfully collaborating with the community and getting honest feedback on the product.

That’s why we switched to Discord. Unlike Slack, it was built with communities in mind from the get-go. What we also really like are the voice chat capabilities. We feel that voice chat helps us to create a good and personal connection with community members. This is vital for successfully collaborating with the community and getting honest feedback on the product.

How do people find out about the community? How do you make sure it keeps growing?

In the beginning we were really looking for a certain type of developer to join our community. We wanted these first members to become ambassadors for Qovery.

People who maintain a more active online presence than most developers […] are often enthusiastic and passionate about technologies they come across and feel a natural urge to share their experience with others. They are ideal community members, as they spark conversations and help you spread the word about the product through word-of-mouth, articles, and podcasts.

In order to find them, we looked at people who maintained a more active online presence than most developers. For example, on Twitter or YouTube, or via blogs. We also got in touch with people who are organizing developer events or talk in public at those events. These people are often enthusiastic and passionate about technologies they come across and feel a natural urge to share their experience with others. They are ideal community members, as they spark conversations and help you spread the word about the product through word-of-mouth, articles, and podcasts. In fact, we even hired someone who ran their own YouTube channel with 30k subscribers. By sharing their experiences with their own audience, they’re still bringing in new community members to this day.

Lately we’ve also been experimenting with cross-community resource creation. Such collaborations can be mutually beneficial to both communities. For example, we could create a resource explaining how to deploy your application via Qovery by filling in a form in Typeform. This is interesting to both communities, because it demonstrates new possibilities for both products. Hopefully this will encourage users of the other product to also try out your own and vice versa.

How do you keep your community lively and positive?

Especially when a community is still in an early phase, it’s up to you to keep the discussion going. That’s why we’re actively participating in conversations and going for the extra mile, even when the questions are only partially related to our product. For example, we assist people in choosing the right database for their application. That shows our users that we care about them and that we’re really trying to involve them in the product.

We also share many resources with our community in the form of guides, tutorials, and articles. And we’re sharing news and product updates with them as well of course. We plan to go further and organize online and offline events too.

How did engagement change when you grew from the first 50 members, to more than 600 members? Any challenges anyone can learn from?

Not that much actually, but it is becoming increasingly difficult for me to keep engaging with everyone in the community as much as I’d like to. As a co-founder and CEO, I sadly can’t spend all my time talking to community members. I often have about 15-25 calls per week now, so it’s pretty busy. That’s why we’re currently hiring a developer advocate to assist me with community engagement. One piece of advice that I would give to anyone considering to hire a developer advocate would be to start looking for one early on. It’s quite difficult to find such a person, as it requires a rather unique combination of technical skills and communication skills.

You recently open-sourced a part of your product. Can you explain why you did that and how it impacts your community?

We did that for two reasons actually. First of all, we’re building our product on top of various open-source software projects. Without those projects, Qovery probably wouldn’t exist. Therefore, we felt that we had to give back to the open-source community in some way. Open-sourcing a part of our application is one way to do that. We also introduced a special tier for open-source projects, so they can use our full product for free. This is important, because many of these projects are being run with limited resources.

The other reason for open-sourcing is to gain the trust of our customers. As a startup, we haven’t built a name for ourselves yet. However, in order for our product to work we require access to the customer’s account at a cloud provider like AWS. That’s a pretty big step for companies, as they are probably hosting other applications or sensitive data there as well. By enabling them to review our source code, they can see that we’re not doing anything weird with their account.

What’s interesting in terms of community is that we can also leverage the community around the programming language in which our software was written.

What’s interesting in terms of community is that we can also leverage the community around the programming language in which our software was written. Many applications for application deployment in the cloud nowadays were written in the Go programming language. Mostly because some widely used projects also use Go, such as Docker and Kubernetes. However, we decided to write our software in Rust, which is a fairly new programming language that is quickly gaining ground. There aren’t that many programs written in Rust that deal with application deployment yet, but there is no reason why the language wouldn’t be suitable for that purpose. So our product is also interesting to them, as we demonstrate how the language can be applied to other domains as well.

How do you keep power users engaged? Do you give them special benefits? Or how do you make sure that they start writing about you?

We have goodies, haha 😜 That’s a good start for building a personal relationship with them. But the essential part is that we spend a lot of time with them and try to be as easily available to them as possible. To that extent we have a private voice chat channel in Discord between those users and our team.

I strongly believe that spending one-on-one time with power users is key in forging a strong relationship.

I strongly believe that spending one-on-one time with power users is key in forging a strong relationship. That’s also how we approached the community building with the motorbiking community. I went out for a ride every weekend on my motorcycle. Together with existing community members and also with new people. And I noticed how much they appreciated the fact that I took the time to get to know them and spend time with them. That translated into a lot of goodwill and word-of-mouth, helping the community to grow.

The downside to this approach is obviously that it doesn’t scale well. It’s not really possible to automate the process, as human interaction is very important. That’s also why we’re looking to hire a developer advocate, who can assist me with this.

How do you involve your community in improving your product?

Again, I firmly believe that it should be easy for people to reach out to us and provide their feedback. It's our job to make this process very simple for our users.

As a user, I shouldn’t be bothered with the tools you’re using to manage your product. I just give you my input, and it’s up to you to decide what to do with it and how to document it.

Sometimes when I provide feedback for other tools, I’m told to submit that in the form of a GitHub or JIRA ticket instead. I hate it when that happens. As a user, I shouldn’t be bothered with the tools you’re using to manage your product. I just give you my input, and it’s up to you to decide what to do with it and how to document it.

That’s why we have a support channel in Discord and also an Intercom chat bubble on our website. When we receive feedback there, we’ll make sure that it ends up in the right place. We also have a public roadmap and voting board, where people can also submit feedback if they want.

By the way, Intercom is a perfect companion tool that I recommend. It’s much more than just chat, as it also functions as a CRM for SaaS products.

One piece of advice you would give to anyone that is building out an early community around a software startup:

Be sure you love what you’re doing, because you must be involved at a 1000%. Don’t expect to have someone else doing your job right from the start. You must love what you’re doing and not give up. Your community needs your attention, and you have to enjoy it.


Thanks for reading this issue 🙏

Next week we plan to have another cool newsletter for you 💪, stay tuned, and subscribe if you didn’t yet. Also, be sure to check out our RSVP page for the Build With Users Jam next week!

✌️ Cheers,

Steven, Lennart, Gino, Frank