Product development is complex, there’s no way to deny it. There are a lot of factors to consider when building a product, from product-market fit to the technical implementation, and while both aspects are very important, the first one is crucial. After all, it doesn’t matter much if your product is a technological marvel, if no one uses it. Not only that, but it could be that you’ve invested a lot of time and money in something that doesn’t solve anything. That’s why it’s vital to get that first part sorted from the very start. On other hand, it’s difficult, if not impossible, to know for sure if a product will succeed without testing it. That’s where no-code and low-code solutions enter the conversation.
No need to reinvent the wheel
There are a multitude of tools that require no knowledge of code to use and allow you to create products such as marketplaces, content management and dashboards (to name just a few).. Launching a first iteration of a product based on an existing tool is a great way to test its viability, without much risk. Even though most of them aren’t free to use, and some of the features may need to be cut or adjusted due to possible limitations of said tools, you will shortly see a return on that small first investment of time and money.
There is a catch though: it’s possible that a single tool won’t cover every need to run a first iteration of your product. In those cases, a low-code approach may be a better fit.
From no-code to low-code
As its name suggests, low-code involves a certain degree of coding to integrate multiple tools into one solution. The main advantage of this approach is a much bigger flexibility in terms of what is possible to do within the constraints of existing tools - not only is possible to add as many as needed, but it also allows some degree of customization, as most tools have embedded code options (for example, to add your product brand and styleguide elements). Embracing low-code also opens the doors for more specific tools that cover critical features, such as authentication or payments.
Whilst a low-code solution can remove a lot of the technical talent needed, particularly in terms of developers, it might not remove it completely. Complex projects, and those involving multiple solutions that need to work together, may still require technical expertise. In fact, Whitesmith product teams often take on this role, identifying the best no-code solutions for a project and weaving them into a single cohesive product far more quickly than through more traditional development approaches.
Defining a low-code solution
You may wonder how this low-code approach could be applied to your product. Since there’s a ton of possible scenarios, I’ll use a short practical example: As a videogame collector myself, I might want to build a platform that allows me to keep track of my collection and trade games with other collectors. A simple concept at the core, but with a lot of room to scale in complexity - as many ideas and solutions are.
Here’s how it could be built following this approach:
- User management: Clerk would allow to streamline everything related with user profiles - Registration, authentication and profile settings.
- Data: To get accurate metadata for every existent videogame, it would be essential to rely on an external API, such as TheGamesDB. To store each user collection, as the trade requests, Firebase could be the solution.
- Interface: As the core features are essentially collection management and trading, a bit more resources and attention could be given to their user interface. As such, using a frontend framework that could provide us all the components needed out of the box, such as MUI, would give us flexibility to build a custom interface at a faster pace.
This is naturally just an offhand example, where I haven’t examined the feature specifications in depth. However, it can definitely give you a glimpse of how a low-code solution can be assembled.
Scaling from low-code
The end result of a low-code implementation shouldn’t be viewed as entirely disposable after the initial validation period. While the main goal of this kind of approach is to launch your product faster and more efficiently, it doesn’t mean that all the work done previously has to be discarded when the time comes to scale up. The modularity of this type of product allows for a gradual replacement of each third party tool, leading to a fully custom solution.
Logically, a continuous development with the same team that assembles the initial low-code product is the most obvious path for a smooth scaling process. Alternatively and under the right circumstances, a switch to an internal development team isn’t out of question either. Considering that a low-code solution is built, evidently, with less custom code, the hand-off process would be ideally less complex.