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.
- La primera decisión fue elegir la herramienta o plataforma en la que desarrollar toda la web, para ello nos decidimos por Webflow por su potencia, versatilidad y gran experiencia del equipo.
- 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.
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.
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...
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.
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.