The challenge of building a marketplace without code

When we face the challenge of creating a new digital product, the following question usually arises: Should we develop it programmatically? or perhaps it would be better to use no-code or low-code tools for this purpose?

The answer to this question is not simple and depends on the use case, the complexity of the product, the required robustness and performance, as well as the purpose of the digital product.

This challenge was posed to us when we started the ideation and development of My SpaList, and in this post we are going to explain how we did it and the reasons that led us to make the decisions.

What is My SpaList?

My SpaList is a search engine and directory of professional massage therapists and spas.

There are two types of users on the site, on the one hand those who are interested in searching for these services and on the other hand the professional users who see the product as a useful tool to get clients. The latter are those who will have a login to create their profile, users who only want to search and contact a professional do not need to register.

Which no-code tools do we choose at the beginning?

Although the product had to have a lot of functionalities from the beginning (it was not only a minimal product to validate hypotheses) we decided to go for a non-code stack of tools, which over time have been changing.

• The first decision was to choose the tool or platform in which to develop the entire website, for this we decided on Webflow because of its power, versatility and great experience of the team.
• The first decision was to choose the tool or platform in which to develop the entire website, for this we decided on Webflow for its power, versatility and great experience of the team.
• To allow users to search for massage therapists and spas, as well as to mark them as favorites, we chose Jetboost at the beginning.
• Sendgrid is used for email confirmation and newsletter sending.
• The uploading of all images of masseurs and spas is done through the Uploadcare widget.
• For the verification of emails and phone numbers we have chosen to use the Twilio API, as it makes it much easier to manage this process.

And where is all the massage and spa information stored? All information that is publicly visible is stored in the CMS provided by Webflow, however, due to limitations of that CMS and to limit access to private data, the rest of the information is stored in the Memberstack account of each masseuse or spa.

Behind all this accumulation of tools there is quite a lot of logic, how is it managed? To solve this we bet on using Integromat for the actions that involve connecting multiple tools, along with Javascript code for the logic inside the web page.

How do we manage all the logic behind the application? Squeezing Integromat

As the development of the web application progressed we saw how the complexity of the application was growing, from Integromat we interconnected all the tools mentioned above, added business logic and recorded the actions to then be able to perform an analysis of such data.

Below is a screenshot showing all the scenarios that have been created, from the simplest ones with only 2 modules in the case of launching email alerts when there is an error, to the 39 modules used in the scenario that manages the data update of a registered user.

One of the most complex scenarios we have developed is the one that detects changes in the profile of a masseur or spa.

We have divided it into different sections: personal information, contact, address, details, locations and employees, which helps us a lot to understand and manage it in case of any error.

In this flow, information is obtained and modified from both Webflow CMS and Memberstack, recording some actions in Google Sheets for further data analysis.

Another interesting scenario is the one developed to validate a user's email, the user will receive a verification email, and after clicking on the verification link this scenario will be executed.

In which through the Twilio API we will verify that everything has gone correctly, we will update this information in Memberstack, we will register the information in Google Sheets to analyze the data and we will redirect the user to the web, if at any time there is a problem or error he will be redirected to a web that will inform him of what happened.

Web applications with Webflow, lights and shadows

For the realization of the web from the beginning we bet on Webflow, it is a tool that offers us an enormous versatility to develop and design.

For the design of the public part there were no major problems, and it was possible to correctly layout what had been designed, with some minor tweaks with Javascript. Here we show you the Home and a profile page of a therapist.

Creating the private section

However, for profile management it was necessary to have a private section, which required much more code to work properly.

On the one hand, Memberstack is used to configure subscriptions, payment and access limitation to some pages. However, as mentioned above, the public information is stored in the Webflow CMS and the private information in Memberstack, so setting up a page from which to modify all this information was not an easy task.

For this purpose, it was decided to divide it by sections, in each section the user can modify a part of his profile, personal data, address, photographs, details...

To manage all the logic it has been necessary to use Javascript code, with this code calls are made to the API that verifies the phone number, manages how to save the hours open to the public, the services offered, the prices offered, the addresses with geolocation or the uploading of multiple photos (using the Uploadcare widget).

It is at this point that we see the limitations of non-code tools, when we need more customization or to manage something in a more complex way.

For the storage of public information, the Webflow CMS has been very useful, but we have found its main limitation, and that is that each element of a collection can only have between 30 and 60 fields (depending on the contracted plan) where to store information.

Limitations of no-code and solutions found

When choosing a no-code tool stack for our project it is important to know what functionalities we are going to need and what limitations exist, since it is very likely that some functionality will have to change a little to adapt to a tool, or it may be necessary to discard a tool because of some important limitation it has.

The experience working with all this set of tools is very useful to know which are the limits of each one of them, since it can happen that we bet on the use of a tool and in the end a limitation arises that totally blocks the development of our idea.

Data storage

Storing and managing the data in two different places, the public ones in Webflow and the private ones in Memberstack, has been quite problematic, since at all times you have to access data in different places and maintain the concordance between them.

It has been necessary to use a lot of code for this, since it was not enough to have a single source of data, Webflow has limited fields and exposes the data it stores in the detail pages of an item, on the other hand Memberstack shows the private data of the person who has logged in, so it does not serve for the management of public data.

Whenever possible, it is advisable to maintain a single source of truth where the data will be stored, since otherwise it becomes more complex to have several data sources correctly synchronized, and it is at this point where inconsistencies may arise between them.

Logic management with Integromat

Although Integromat is a more flexible and powerful tool than Zapier, as the volume of scenarios, modules and connected tools grows, any small change can cause something to become unconfigured or stop working, slowing down development. In addition, it is not possible to have scenarios in staging or draft, so changes are always being made in the production version, with the stability risks that this entails.

Searches and filtering

To perform searches and filtering we chose Jetboost, it is a very practical addon for Webflow as we commented in this article comparing the filtering systems that exist in Webflow, but we quickly found its limitations.

The search in a directory of this type is based on location, since the user does not want to travel for hours at a time, so a location-based search was essential.

To solve this major problem we decided to develop our own product that would allow us to perform searches quickly, with geolocation and the possibility of displaying results on a map. We are at the moment developing this product to give everyone this complex searching tool. We'll keep you updated.

‍