#19 : Meeting with Prello

written by
Clara Cros

During this 19th meeting we went to the WeWork avenue de France, in the 13th district of Paris, to discuss with Nicolas and Johanna de Prello.

Johanna is a Product Builder in the company and before coming to Prello she first held the same position for two and a half years at PayFit.

According to her, the term Product Builder is a perfect representation of her job because it encompasses the roles of Product Manager, UX Designer and NoCode Maker. Johanna even confides that the PayFit teams were the first to use the term Product Builder.

Nicolas, Head of Product, started in industrial design. He initially got into NoCode because he wanted to be an entrepreneur. He also worked with Tinkso for more than a year and that's when he was able to learn more about NoCode.

Today he is in charge of the department that includes Product and Tech at Prello: product and tech are effectively one and the same team; there is no distinction. They don't have a CTO but a Tech Lead, Peter, with 20 years of traditional development under his belt!

The genesis of Prello

Prello, co-founded by Sébastien and Ludovic, was born in the summer of 2021. They brought to France the concept of shared purchase of second homes, which was already widespread in the United States. Sébastien and Ludovic both had a strong background in real estate and in tech thanks to their previous professional and personal experiences.

Nicolas is the first employee of the company and saw the project being born alongside them. He is the one who initiated the integration of NoCode at Prello. He quickly saw this technology as a way to move fast, not just a financial advantage. According to him, NoCode was also a way to take a step back from the technology in order to focus on user and internal needs.

However, it is important to specify that they did not launch on a stack NoCode without first asking the question if their product was NoCode friendly (especially in terms of data logic, workflows and processing of operations). After realizing that it would be totally viable, they chose to use Bubble (for the application part) and Webflow (for the showcase site).

The development of the first version of the website was outsourced while Nicolas was in charge of developing the first version of the application. The latter had to be developed quickly in order to validate their second fundraising.

Both fundraisings were completed in less than a year!

Their first POC was completed in one month, from scope to design to integration and development. At the time of the launch, there were between 10 and 20 daily users and with the arrival of marketing and communication, they are now on much higher volumes. This has been followed by numerous recruitments, making them grow from 3 to 50 employees today, including 12 people in the product team.

Prello's definition of a product builder

At Prello, the teams are organized into 3 divisions and each division manages a set of products. Each of these teams is made up of several Product Builders, each with their own area of expertise:

  • A more techy product builder who will essentially take care of the architecture and back-end logic
  • A Product Builder plus designer, who will take care of the UI/UX and front-end integration
  • A Product Builder with a more Product Manager profile

So there is no single definition of a product builder and everything depends on the profile and skills of each person, on what they are comfortable with. The same goes for the choice of the division in which to work and evolve, the aim being that everyone can express themselves on their specialties.

According to Nicolas, versatility is a good thing, and is even very important at Prello, but having a specialty is also a significant advantage because it allows the person to push the discipline in which he or she evolves to the maximum.

For her part, Johanna chose to work in the Client division (in other words, the Property Management Business Unit), a division that requires strong logic and the ability to work with complex rules. These are aspects that Johanna masters with serenity and that make this choice perfectly suited to her.

On a daily basis, she works with property managers and among her latest projects is a calendar allowing co-owners to book stays in their property. At the heart of this application is a dynamic calendar shared and synchronized in real time between the different co-owners and the Online Travel Agencies (Airbnb, Abritel, etc) via API.

The nights not used by the co-owners are offered for rent on these platforms and the rental income is distributed at the end of the year among the co-owners.

A real challenge for her in terms of application logic but made possible thanks to Bubble and Xano. These two NoCode tools allow to set up complex logics; to create custom plug-ins or to use existing plug-ins in order to bypass their native limits.

It's even crazier when you consider that Johanna didn't master Bubble when she arrived at Prello in March 2022!

A V2 is planned to add new features such as the management of expenses and income according to the number of shares and what has been consumed by each!

View of the calendar of a co-owner - desktop

A real organizational twist

Until now, all Prello products have been started in agency mode, in a V-cycle, and therefore in a fairly linear way with specific stages, namely: scope phase, design/integration phase and development phase. With time and with the growing number of products they started to have congestion on the products already in place and the choice to move to agile mode was then recently taken. According to Nicolas, the V-cycle is adapted to the launch of POC or MVP. The agile mode allows us to continue to develop the product as it becomes more and more complex.

From now on, the whole design/user journey part is worked on continuously, the PMs and designers constantly feed the reflection; while on the delivery and production part the work is timed and sprints are realized.

What tools?

  • Notion for project management, stories, collaboration with the business and all documentation: workspace by team; management of agile rituals, and a myriad of databases (load tests, processes, tools, benchmarks, data inventory etc.)
  • Hubspot for the CRM and deals part
  • Miro for user flows and technical diagrams (which also serve as documentation)
  • Bubble has allowed them to develop a home-made admin for sourcing and scoring goods but also a B2C project management space, a B2B partnership space and MyPrello, their client application
  • Xano mainly for the back end and they are generally very open about APIs

At the moment the discussion of having a dedicated front end is underway (notably WeWeb). This would allow them to no longer have to duplicate the data as is the case now and thus have a separate front and back end.

Notion - User Story Mapping

Miro - Example of User Flow

Profiles and skills development

The company recruits profiles that had not necessarily touched the tools used internally before. They are based more on the appetence, the competence, the curiosity... but also on certain prerequisites:

  • It is important that Product Builders master traditional code (Stack JS in particular) because this position requires real technical knowledge.
  • PMs must be versatile and traditional Product Management skills are also appreciated (Discovery, UX sensitivity).
  • Product Builders must have some UI/UX skills.

And for the increase in skills, each one helps the other to perfect his mastery of the tools!

For example, Johanna had never worked on Bubble before she arrived, as did other tech profiles. She learned through maintenance and testing, hand in hand with one of the product builders, and then she ended up getting more hands-on with the code on more and more complex features.

However, there are rituals, such as the Sprint Review, which have been established to show the work done by the teams and with the aim of standardizing the user experience on all their apps. Design Reviews are also put in place in order to find solutions together, to challenge each other's work and to share best practices.

Even if they do not push everyone to use all the tools of their stack, many processes that everyone can use are put in place and isolated processes are avoided as much as possible. This makes it easier for everyone to back up when an employee is absent for a certain period of time. For each tool, methods and best practices are put in place. These are the subjects that are discussed during the Design Review.

Of the 12 people on the Product team, NoCode is already well known to everyone because it is an integral part of Prello and its day-to-day operation, and has been since the birth of the project.

NoCode and TV appearance

Prello had the opportunity to present its product on a national television show. The information came to the table about a month before the said television appearance. At that point, they began to anticipate the issues:

  • Many scenarios have been tested
  • Numerous load tests were performed to see how far the tool could go

Finally, a telephone exchange with the Bubble team was also organized. After that, the Bubble team could not give them any certainty about the possibility for the tool to support a large volume of simultaneous connections. This finally convinced them, only a few days before the TV show, to disconnect Bubble to avoid any risk. They then turned to Webflow and mounted 4 Webflow instances on a server redirecting the traffic in load balancing.

Load tests were then carried out again until the day of the launch. In the end, everything went very well and Webflow was able to handle the large number of visits perfectly!

This TV appearance is + 200 000 visitors with big peaks of 50 000 connections over 2/3 minutes.

The last word

According to Nicolas, the choice between NoCode and traditional development must always be considered. NoCode tools are a real (r)evolution on many aspects (democratization, establishment of a common language within the whole production chain, launching of ideas and evolution of these ideas). On the other hand, it is essential to know the limits and constraints of NoCode tools to be able to deal with them. In this sense, traditional code and developer knowledge are sometimes necessary and that's why we often talk about LowCode at Prello.

The 3 big glass ceilings encountered with NoCode by Prello and that we should keep in mind according to Nicolas:

  • The performance and cost of performance on these tools
  • The subject of the mobile application
  • The collaboration part: it is complicated today to be more than 1/2 person on the same project to do continuous integration because the tools are mostly designed for micro teams or even teams of one person

These are subjects on which maturity is not yet at its maximum and it is for these reasons that they keep an essentially LowCode balance.

The additional developments, on traditional infra, come in complement to reinforce their stack on subjects such as the versioning, the installation of tests of integration, system of monitoring and alerting.