Entrepreneur.com recently published an article on how to properly choose a low-code platform. (Original title: How to Choose a Low-Code Development Platform That Has Your Best Interests In Mind). The title is a bit misleading though, because basically the article is only about pricing and other, important factors are left out. Here is the essence of this article. I've included go and no-go cases for each variation:
If the pricing model of an LC/NC (low-code/no-code) platform is based on the number of end users, this will potentially cost you dearly. This does not mean you as a user of the SaaS, but the users of the finished app. I.e. each new end user costs you X€ per month.
For a small app, which may only be used by your 40 employees as users, this may very well be something. Especially if the other features speak for themselves.
For a B2C app with which you want to reach hundreds of thousands of users, this can't work.
One variant for many SaaS products is the Pricing Pro "seat". In this case you pay X€ per month per employee account. This can be quite expensive per account, but still profitable on the bottom line. Compared to the above method, these costs are much easier to forecast and keep.
If you have few developers and the possibly high costs can be justified. It should also be ensured that everyone really uses the tool.
If you have a large developer team, the cost per account is high and only a few developers actively use their account. There may be cases where everyone needs access to the back-end but only a few need to use the features. If the tool does not allow you to differentiate between the roles (e.g. between "Viewer" and "Admin"), then this becomes unnecessarily expensive.
In advance and before PETA boycotts this post: Animal in English means something like "level" or "rank". No animals are sold here. I.e., you pay X€ per month, depending on which level you book. You know this from freemium models and very many SaaS tools set their pricing like this. Basic, Premium, Enterprise etc. The advantage here is that you have a fixed monthly or annual price. But this can also be very high.
If you want to invite users and developers without incurring additional costs. But also when the cost of the features offered is profitable.
If the monthly or annual costs cannot be balanced against the benefits and revenues. For example, if you sign a yearly contract because it costs 25% less than the monthly plan - but you realize after 3 months that your idea doesn't work... yes, then it will be 9 expensive months.
Last but not least, the costs per unit of usage. Often these are e.g. X€ per GB data storage, X€ per API call or X€ per own units of the tools. Most recently, Bubble.io introduced their unit "Workload Units" and set the pricing accordingly. The advantage here is that you really only pay for what you use.
→ By the way, Alex & Lilith talked the other day about Bubble's new workload units and what that means for Bubble Apps now. Check out the episode here.
You want to keep your product costs as flexible as possible. Or even if the tool calculates units that are irrelevant for your product - because here you can use important features but keep the costs low.
The tool makes it unmanageable how they calculate the units. The necessary performance for your app is directly related to the units, which are also expensive. Or even if you need a lot of units, but they are not really relevant for the added value.
I have most recently built an app using Glide. The limiting factor is the number of rows I can have in the database. If I had more than 500 rows, I would have had to pay $25 per month. That would have been too expensive for my application. But for the added value of the app, it was not important at all that Glide collects the entered data as rows. So I bypassed the system. How? I'll tell you in episode 88 of the VisualMakers Podcast. This way!
