No-code is no longer just a nice gimmick for a few hobby developers who want to save development time, but has long since established itself as a must-have for companies, founders and makers of all kinds. And although no-coding is becoming easier and easier, choosing the right tool is becoming increasingly difficult. The reason for this is that new tools and more and more features are being added to existing tools.
As a provider of no-code tools, your main goal is to win over more and more users - preferably all no-coders! But no no-code tool can satisfy everyone and everything. Even in the world of no-code, there is no one-size-fits-all solution. The only problem is that some providers want us to believe exactly that. Claims such as "The most powerful no-code tool in the world!" or "The only no-code tool you will ever need!" may be good for marketing, but bad for potential users. Of course, tools want to show their best side. But it is just as important that potential users know where the tool's limits are. However, we cannot expect a comprehensive and objective no-code tool comparison from the individual tools. So the only thing that helps is to compare them yourself.
Unfortunately, the whole thing is a little more difficult than you might think. This is because different tools have different features, prices, difficulty levels, strengths, weaknesses, use cases and so on. Comparing all these dimensions across several tools is quite complicated. And even impossible if tools do not provide certain information or are not transparent. That's why we've put together a checklist that you can use to make sure that the tool you choose is right for you.
These are the points that we at VisualMakers consider to be particularly relevant. The checklist as an interactive questionnaire including AI-supported recommendation is available here: visualmakers.de/no-code-navigator
First, define what you actually want to build. "I already know that!" you might be saying. "I want to build an online store!". But as what? As an e-commerce store? As a peer-2-peer marketplace? Do you need a mobile app for it?
At VisualMakers, we therefore divide everything into three areas at the top level: Apps, websites and process automation.
Apps can then be divided into mobile apps or web apps. Mobile apps in turn depend on whether you want to publish the app in an app store (so-called native apps) or not. The latter is referred to as progressive web apps (PWAs). These can be installed on the home screen of smartphones without having to be published in a store beforehand.
With websites, the question arises as to whether it should be purely an information site or whether users can also register and log in there, for example. Should the website have a check-out or store function? Should it be an e-commerce store or more of a marketplace?
With process automation, the whole thing is a little more complicated. More on this in the section on prices.
Some time ago, we published a blog article on various pricing models. You can find the article here.
You can try out almost all no-code tools free of charge. Some are limited in time, others are restricted to a few functions. However, you will be asked to pay for pretty much every tool in order to make your finished project really usable. In most cases, you can't publish the app on the free plan or the number of users, workflows, database entries, etc. is severely limited. But that's okay. At the end of the day, the companies want to earn money and offer great tools to do so. Nevertheless, as a user you want to make a decision before you pay. That's why you should take a close look at the pricing of the tool.
There are two types of pricing: monthly subscriptions or pay-per-use. Most offer the former, others offer a combination of both, for example Bubble or Make.
The most important features included in a pricing plan are usually quickly apparent. Here at Flutterflow, you can immediately see that the $30/month plan does not include the ability to publish the app to the Apple and Google App Stores. If publishing is a compelling criterion for you, then you know that you pay at least 70$/month with Flutterflow. Based on this, you can then compare it with Adalo, for example.
With these models, the total costs depend on parameters such as the use of storage space, active app users and the like. This makes it more difficult to estimate costs, but depending on the use case, it may even reduce costs.
Bubble, for example, has a monthly subscription including a limited number of so-called workload units (WLU). This is the unit that Bubble now uses to determine the working capacity of apps. So if you use up the WLU included in the monthly price, you pay extra. So you need to be able to predict in advance how your app might be used. It may even be that the more expensive monthly subscription pays off compared to the cheaper one.
But this estimation is quite difficult. Especially if, as in the case of Bubble, the calculation of these units is not transparent. The situation is different with iPaaS tools such as Make or Zapier.
With automation tools such as Make, Zapier, Latenode, IFTTT and others, there is also a limit in the monthly prices that is linked to certain parameters. With Make, the so-called operations are limited, with Zapier it is the zaps. What exactly this means for the respective platform is best explained by the platform itself(Make.com article on Operations - Zapier article on Zaps).
For you, this means thinking carefully about which billing model suits you better. Do you want to build just one automation or 100? How many steps should your automations have? Which links to other apps do you need? etc.
There is a good rule of thumb for estimating the difficulty of a no-code tool: the more you can do with the tool, the more difficult it is to learn. This relationship is by no means linear and difficulty is of course subjective. Nevertheless, it is worth keeping this rule of thumb in mind.
Here is an example using tools to better assess this rule.
The Carrd tool is probably the simplest way to build a website. However, the tool quickly reaches its limits. Webflow, on the other hand, is one of the most powerful no-code tools for websites. However, learning and mastering Webflow takes time.
It is similar with Softr and Bubble, for example. Softr is much easier to learn and master than Bubble. As an absolute beginner, you can create finished web apps in just a few hours with Softr. The same app in function and design will take days, if not weeks, with Bubble. However, Softr also quickly reaches its limits when it comes to customizing functions and features. With Bubble, this will take much longer - or not happen at all.
With light tools you are fast, with heavy tools you get far.
The decisive factor here is your assessment of what your tool should be able to do. For well-defined apps such as a CRM, an employee directory or similar, you can be sure that you have the perfect tool with Glide or Softr. If your idea is much less defined, it may well make sense to invest your time in Bubble, WeWeb or Flutterflow.
Which functions a no-code tool must have depends on your goal. There are clearly defined functions and what we call "implicit" functions.
Clearly defined functions are e.g. "Can I use it to accept payments?", "Can I connect Excel?", "Can I embed custom code?", "Can I export the app code?" etc.
Implicit functions are somewhat more difficult to recognize. These are usually features that you want to build. But to build these, the no-code tool must have the necessary functions. For example, "Can I build an onboarding process in which the user is guided through various steps? You should be able to see a process bar."
Two things are particularly helpful here: to see which apps have already been built with the tools and to see which templates are available.
Most no-code providers feature case studies that show what great projects have already been implemented with the tool. So there might be something there that is just as or similar enough to what you want to build. This is a good indication that your idea can also be implemented with it.
Templates are more or less templates for apps. They are prefabricated and usually ready to use. The idea here is that you save yourself the hard work and only have to make design adjustments and other small adaptations.
The same applies here: light tools will get you fast, heavy tools will get you far. So you should be clear about which features you want to offer.
Users do not refer to the end users of the finished app, but to those who have to work with the no-code tool. Either because they build the app from the outset, or because they are responsible for maintenance and enhancements later on. If these people are experienced developers, they will easily master far more complicated no-code tools. However, if they are colleagues from the marketing department, for example, then the no-code tool should have the appropriate level.
For example, most people will quickly get to grips with the no-code database Airtable. Working with Xano as a database, on the other hand, requires far more technical skills.
It is better to talk to these people than to just think about who would or would not be able to cope with it. Perhaps they are experienced no-coders or those who would like to become one.
The truth is, the royal road to the no-code tool is still a path that everyone has to take for themselves. There is no universal solution (yet). But with clear ideas and good research, you can find the tool that suits you perfectly.
Our No-Code Navigator will at least suggest two suitable options as a no-code tool. And if you're still struggling to decide, there's always the option of joining our Slack Community. There are 650+ other no-coders waiting for you and your questions! Click here for the community.
And don't forget: no-code goes beyond the tool. It's a mindset, an exciting promise of autonomy and speed in a world where software has long set the tone. We have the best introduction to this world: our No-Code Fundamentals course. Over 700 graduates have already successfully mastered it! Click here for the course.
