How to evolve a #nocode project with a €1M in revenue
🇪🇸 First. Do you want read this article in Spanish? Check it here.
First of all, let’s get situated, this article is a like a “Part II” of the first article we talked about setting up a #nocode project, if you haven’t read it yet I recommend you to read it before 👇
It’s been a few months since the validation of our project. Edify with #nocode, a few months of chaos, learning and above all… growth, there are undoubtedly 4 key points that we have learned with #nocode.
- Creativity to the power → If you want to, you can. You just have to have some creativity in the format of “explaining” to the #nocode that you want.
- Everything in duplicate → And when I say in duplicate I don’t mean doing x2 of work, I mean having a backup of what is going to be executed. I love Zapier, but it can fail and we can’t lose a +300K€ lead because of a “Zapier error”.
- Don’t look under the rug too much → It’s normal to sneak in some noise or “extra” processes that you wouldn’t normally do if you were doing custom development.
- Validating is simple, scaling is complicated → #Nocode is a fantastic way to validate ideas, processes and services no doubt, but when you want to scale, there it’s a bit more complicated.
And for that last point, I am writing these lines.
How have we been able to scale a product that turns over +1M€ with #nocode tools?
It seems that when you go in with a particular technology as is the case with #nocode unless you have that great technology team you have to marry this technology, the typical phrases of:
“Leave it alone, if it works don’t touch it.”
They are more common than I would like and for a while I had that perception myself. Hey, we’re selling, we’re billing, what’s the need to change this flow?
The problem was basically in scaling and maintaining the structure, with #nocode.
#Nocode is a fantastic way to validate ideas, processes and services, but when you want to scale you have limitations.
Recalling our initial flow, this flow has been operational almost until December 2021.
This flow was fully operational and functional with it we have exceeded in 2021 the +1.2M€ turnover, and on paper it is very functional and operational. We reduced approximately 40–50% of the time in the creation of opportunities (leads) but the more opportunities that came to us, the more we had to keep (wow… what a surprise 🙃).
We encountered a maintenance problem, we could not give a good service to all customers because the maintenance processes were costly with #nocode.
Particularly with the management of that “wonderful” dashboard of the client, where we centralize all the information of their new home, houses, visits, status, image gallery, etc….. Once we had a few dozen clients, we had overbooking of work, the commercial agents could not cope with the volume of work. We had a scalability problem.
We spent some time doing different tests, we tried different tools to keep track of the reforms and to act as a link to communicate to the client. Webflow and its CMS was too limited and too tight for us.
The first tests were very “disparate” from testing the dashboard to be a simple page in Notion. (Functional, but too simple for the level we were looking for) to creating with Retool a panel with different options.
The problem is that we couldn’t create anything so “impersonal” because in the end it was communicating and the new home of that client. Besides I am very MAP (Minimum Awesome Product), personally we had to show a more personalized experience.
Obviously without having to invest a lot of money in a technical team (which at that time we did NOT have yet).
Those were the first signs of telling ourselves that we need technical equipment (developers) NOW.
During the hiring process, (which due to the pandemic and the market situation is almost easier to find a unicorn than to hire programmers), researching different tools I came across something new, something I hadn’t seen before. Strapi.
It was a content manager, but focused on API, instead of managing and getting an interface (Webflow style) what you got was an API with JSON objects.
It seemed interesting, i.e. I was the owner of the content, I got a simple JSON with which I could manage the information and “paint” it to my taste and needs, without the limitations of Webflow.
*Mention that I studied computer engineering and I was front-end, so it was nothing “new” I have worked with this format and I was quite comfortable working with it.
It seemed interesting, I was watching a lot of Youtube videos, reading some posts or articles (I recommend you this one). And I decided to install it on localhost to test it.
In less than 5 minutes I had the environment running locally, creating a simple endpoint in another 2 minutes.
The approach is simple. You install the package
You set up the 2–3 steps and you will have access to a panel to start configuring your collections, create the structure of your collections, with unlimited variables, unlimited processes, unlimited size… a backend-as-a-service!
By configuring all the necessary variables we needed, it generated a directory of endpoints (APIs) to work with… we only had to paint the data we received in JSON to have a more personalized experience.
Strapi could solve this scalability process (or at least validate more critical points) at a cost that tended to 0, without having to invest in a fully autonomous back-end.
So we decided to create a small service on AWS with a very simple instance. With Docker (what a great invention by god!) we set it up in just 10min. We had our backend up and running 💪.
The next step was to create a base to work on creating those first endpoints, since our main pain was the communication of the works and maintaining that communication was our initial point of work.
We created some collections to do some tests, the creation interface is really simple, the only thing that requires some more “study” is the functionality of the Components and how they can be reused recursively within the same endpoint, but once you have it clear it is simple.
With it we generated a documentation of the API, in format Swagger and from there with those available endpoints we could create, edit, delete everything in that “backend” at the endpoint. Easy.
The most complicated part was completed, with Strapi, we had a CMS manager via API which we could scale a little more, next step, paint data.
Right at that moment we hired the first person of the technical team, a Front-end with a lot of experience with React, so we started to shape that data.
In doing so, we created a small task management system for the renovations and our processes.
All this by means of a “simple” JSON that we obtained from that call, something like this:
In just 3 days we had a task system for renovations developed and ready to test with clients.
In order to integrate it into the system we had, we came up with something as silly as simple… an iframe.
The clients had a dashboard entirely built in Webflow, we wanted to validate this functionality but we didn’t want to touch the client’s dashboard completely. So we decided to integrate a simple iframe inside the client’s page.
his iframe was integrated into Webflow and showed the list of tasks that were available for that client during the renovation.
And not only that… Strapi also has webhooks an internal service that allows you to “notify” when something happens. In our case we used it when a task was completed. Through my beloved Zapier an email to the client indicating “X task of the refurbishment has been completed” 👏
It was a 2x1, the team of reforms that currently had an important block to have control of the reform, now not only had control over the reform in a simpler and unlimited way, but also communicated to the client about the progress.
With Strapi we have saved approximately 25% of the time in the renovation phase, and most importantly we have validated very interesting functionalities and processes for very little money.
I can’t say that we are now super scalable, but above all we have been able to validate in a very short time certain hypotheses we had with clients without having to invest a large amount of money.
We had begun the transition from #nocode to custom code, without it being a giant drama.
With that in mind our “new stack” would look as follows:
From Hubspot we continue to control the entire commercial process of that client, but now with Strapi we control that reform process with fully centralized information, easier for the reform team and above all… with more visual, truthful and simple information for the client.
Win-win.
What 3 things have we gained from this low-code process?
- 1️⃣ Mini-automation → Having full control of that “backoffice” of our own with Strapi we have been able to automate slightly more complete conditions.
- 2️⃣ Validate API product at low cost → We have created our first API models and endpoints, which we have learned some critical points at a very low cost before going to a full-custom-code model, also iterating these models is very very easy.
- 3️⃣ Customization → Obviously being a 100% own product we have full control adapting those endpoints and APIs to our needs and with a front-end that knows how to work with JSON we can do very interesting things with a
higher level of customization without having to develop back-end.
With this our customers have more information. Which is critical, because in the end they are paying an average ticket of 200K€, and it is if not the biggest one of the biggest investments of their lives, they need visibility of what is happening, the more visibility, the more security, the more security, the more confidence.
In a high-ticket product that takes weeks or months to process, it is crucial to maintain proactive communication with the customer.
The next step we have on the table is that final transition to custom-code creating a fully customized backoffice for all phases of our clients, but until then Strapi is helping us to validate and understand what our clients need at a much lower cost than developing custom from scratch… but that will come in part 3 👋
Nothing is particularly difficult if you break it down into small tasks. (Henry Ford)
See you soon…
Did you like the article?
Give it claps! You can hit the clap button up to 50 times and let many more people find and know this article, and of course… don’t forget to share.
Let’s see those claps!
