I always thought that model-driven engineering and low-code tools were the perfect partners for indie developers and solopreneurs. The improvements in productivity and quality model-based solutions bring to the table should be the ideal solution for people trying to launch their idea and build a business around it alone. I like to say that tools could replace cofounders.
But we don’t see this. Low-code tools are not the go-to option for people trying to start a business. And I found this strange. We all know that model-driven engineering is not cool but this didn’t seem to be the case with low-code tools (and in fact, this is the main reason why now all code-generation, model-based,… tools rebranded themselves as low-code). So I decided to investigate a little bit more and even thought about creating one or two apps myself to see if I could find this major show-stopper for indie developers. And it turns out there is a good reason why indie developers don’t adopt low-code tools: the pricing models does not work for them.Low-code tools are not yet the go-to option for solopreneurs or indie developers trying to start a software business. The reason? They are too expensive for this context. Click To Tweet
How much low-code tools cost?
Short answer: a lot. A lot for using them to start a new business where your revenue is still really low and your main goal is to bring more customers in. Again, I’m not saying low-code tools are overpriced as an absolute statement. As you can imagine, I fully understand the benefits they can bring to a big company developing some new internal tools that will save millions to its operational cost. I’m evaluating them under the particular perspective of small businesses trying to make a living with a new software product.
And yes, I’m sure you know a tool that it is cheaper (or even free) and perfect for this scenario. If so, feel free to leave a comment below with the name of the tool. I’ve done an exploratory search focusing on some of the most well-known professional tools that I’m aware of. The goal of this post is not to be a catalog of prices for low-code tools (in fact, I try to avoid giving too many concrete examples for this same reason) but to explore a trend.
Do low-code tools offer free plans?
Yes. All of them. And they are great to get learn how the tool works and experiment with it but they are too limited (in terms of the number of users or “seats”; for instance, OutSystems caps the free plan at 100 users). I don’t think you could even use to try the product-market fit of your idea. Typically, your software will include also a free plan for your own users to let them test your tool before paying for it. That’s just too many users for the low-code free plans.
Other limitations of free plans may be the number of apps (1; again, not good enough if you’re trying out different ideas to see which one gets some traction) or the low-code features (you may be able to use the modeling environment but not be allowed to deploy the generated solution).
Price ranges for low-code tools
So, if the free version is not enough, how much should I expect to pay for a low-code tool if, let’s say, I plan to test out between 2-5 applications and I expect to have around 1000 users on each app? Expect to pay a number in the four figures monthly. As an example, OutSystems enterprise plan is over 5000$/month. And the Mendix Pro plan is around the same number. When you pay per seat (e.g. WebRatio), things get worse and you better negotiate directly with the tool provider!.
Note that the prices above usually include the deployment and hosting of your apps in the cloud of the tool provider. So there are no extra costs to pay Amazon AWS or other similar cloud-based solutions.
Still, the maths just don’t work. Out of the 1000 users in the scenario above, only a small part (let’s say 100 of them, and that’s already optimistic) would be paying customers. And if your service is charging them 20$/month (a common number for a software service that it’s just starting), this means you’ll be making just 2K a month. Not enough to even pay the monthly cost of the low-code tool.
Moreover, you’re also in a kind of lock-in situation. You cannot just pay for the low-code tool one month (the month you develop your app) and then stop. You need to keep paying every month, not only to keep your app running but also to be able to improve and evolve it. And, since you’re starting, this will be often the case.
Is there any way to make low-code pricing work for indie developers?
Pricing models above are reasonable for the customer profile low-code tools are targeting right now. As I said, paying per seat makes sense when you’re developing an internal application where the company benefits from every user of the tool, but not when you’re releasing software with a large number of free users.
I’d like to ask low-code vendors to see in this other audience and try to come up with a pricing model that aligns better with the needs of solopreneurs. Recent movements like Bubble (with a pricing model that scales better) or Generative Objects (that recently went the fully open source route, you pay only if you want them to host your app, but you could host it yourself, same model used by many other open source projects like WordPress) are encouraging examples but I think the low-code tool providers as a group need to realize that there is a huge and underserved market of indie developers looking for a way to speed up their development process. Some providers (like Betty Blocks) charge you depending on the complexity of the tool and not the number of users (which scales better since you don’t pay more when you get more users but it´s still very expensive at the beginning when you have barely any paying user). Another option is to pay just for the resources (bandwith, RAM , disk,,..) your app uses. This sounds great but I’ve seen this only in the low-code offerings by the big five and only works if you are open to “marry them”.
I still believe low-code tools could be a perfect match for indie makers if we were a little bit creative on the pricing model. I don’t have THE solution but I think there are some options to explore.
Tool Pricing models for solopreneurs
As an example, I think some of these alternative pricing models could work for indie developers and solopreneurs:
- Low-code tools could charge only for the number of paying customers of the app developed with the low-code tool (up to a certain ratio of free/paying customers), or
- They could get a cut or percentage of the overall revenue of the software so that the more money the indie developer makes, the more money the low-code vendor makes. We could then discuss whether there should be an upper limit. This is the model that, in the learning to code domain, Lambda School follows or
- They could start charging only after the developers reachers a certain level of revenue from software created with the low-code tool. This is, for instance, what Delphi does with its community edition or Appgyver with its very generous free plan (free for life unless you make over 10 million dollars).
Sure, in all cases, there is more risk for the low-code vendor but still, it’s very small (the “risk” is just not making money, not really losing it since the cost of just keeping an app deployed in its cloud is very low) and the potential benefits are huge if the software product generated with the low-code tool end up becoming a unicorn.
One way or the other, platform-developer relationships today resemble a political battle more than a dance. We need a deeper discussion among all parties to fix this!
ICREA Research Professor at Internet Interdisciplinary Institute (UOC). Leader of the SOM Research Lab focusing on the broad area of systems and software engineering. Home page.
Thank Jordi, I did research on this topic and came to the same conclusion
Jordi — how about a training fee and then a percentage of licensing revenue? That’s what we do with XTRAN, our Expert System that automates the manipulation of computer languages, data, and text. That way, we don’t place a huge burden on entrepreneurs while they are ramping up, and we participate in their success in a scalable way. Information is at http://WWW.XTRAN-LLC.com.
An example of using XTRAN to create a low-code application is one we have done, named TemplaGen, that automates the generation of artifacts (code, HTML, XML, text, IoT feeds, dashboard feeds, etc.) from templates, with extensive data selection / editing and DevOps-friendly features. TemplaGen’s implementation is less than 2K code lines of XTRAN’s rules language, and it took about 30 hours to create and debug. We use it ourselves to automate significant pieces of XTRAN’s own code and documentation. You can see a demonstration at http://WWW.XTRAN-LLC.com/templagen.html. It’s an example of the tremendous leverage on effort that can be achieved using an Expert System with a very powerful rules language, such as ours.
XTRAN represents a different approach to low-code applications. It requires senior software developers, but the payoff is well worth their above-average
Thanks for this interesting post, Jordi.
At fhoster.com, for our “Livebase” model-driven platform, we are going to adopt a quite unusual pricing model.
Let me first clarify that Livebase has a code-generation approach: models are translated into standard web applications (JS rich client, Java logic) that can be deployed on any server with a standard stack (Karaf servlet container, MariaDB DBMS).
This approach allows us to deploy the generated applications anywhere (even on hosting servers located at the customer premises). The only proprietary thing we need on a hosting server is a tiny agent, allowing the platform to deploy a new generated application, or to update an application generated in the past and already in production.
Up to now, we have been charging a flat monthly fee depending on the number of processing cores on the hosting server (no matter how many generated applications it was hosting, no matter how many end-users were using those generated applications).
However, we are now thinking to change our pricing model in a way which we believe is more acceptable and understandable by a wider set of potential customers.
In fact, we realized that the value we provide to our customers is mostly in the modeling and in the generation of the applications, not really in their hosting. Consequently, we are thinking to change our pricing model, and charge customers with a small flat fee for using the modeling environment, plus some fee every time they actually generate (or regenerate) an application.
The generation fee would depend on the complexity of the application model (which we measure in Function Points). The customer has a constant feedback from Livebase modeling environment about the complexity of the model she’s drawing. Customers that regenerate an application already in production would pay only for the difference in complexity between the old e the new version of the application model.
If the generated application is hosted on a hosting infrastructure provided by the customer, nothing is due for that. If the hosting infrastructure is provided by us, then it is charged with a pricing comparable with the price of any managed hosting (i.e. no per-seat or per-core price overhead just because the server hosts an application generated by us).
This way customers would pay the most while generating new applications, would pay less while regenerating applications generate in the past, and much less in the long run, once the application is stable.
Also, customers who generate an extremely complex applications (saving months with respect to manually coding them) will pay for the value they get, even if the generated application will be used by just a few end-users. On the other hand, customers who generate a very simple application (saving just a few days with respect to manually coding it) would pay very little (i.e. consistently with the value they got from the platform), and would still be able to deploy the generated application on their own powerful server and make it available to thousands of end-users with no extra costs.
Any feedback is welcome.
Sounds reasonable to me! Thanks for explaining your approach!
Try Fliplet (https://fliplet.com) and let me know how it goes. You can get a free account and hack around with the tool pretty quickly.
I’ve reached the same conclusions but found a vendor I can live with. CASPIO. They have a $36.00 / mo price point with a good amount of capability and unlimited users. No account user minimums! E.g. Appian is $90/mo but you need to have 100 user minimum. ?? CASPIO also has a $160 / mo (Annual) or $199 / mo (MOnthly) plan that has more capabilities and as a bonus includes a few hours of Dev Support time. This is important because Dev Support is normally $250/hour. So I am going to finish my 14 day trial, do 1 or 2 mos on the $36/mo plan while I learn their platform and then bite the bullet / cliff dive for 2 mos and do the $199 / mo plan to get access to Dev Resources. What I live about Caspio is that they enable each end-user to get individual accounts, authentications and tables (but not entire database but they have record-level authentication.) They also have REST API, SOAP and Zapier integrations. My next contender was Zoho CRM but they seem too lightweight for the money-making webform database businesses I need to build.
One payoff of using a low code tool could be how it helps you define your requirements. If the tool uses models and/or is declarative this could also avert some of the lock in problem. This is sort of like prototyping tools in a way.
The concept that source code is “the asset” you get from an investment in software development is kind of a mith. Most of the time the source code you get is extremely hard to fix and evolve after a few years from the same company that developed, let alone other companies.
In reality, a huge part of the value of a software development effort (and definitely the most reusable one) is the analysis and the deep understanding of the requirements.
With a model-driven platform, especially if the model is based on a standard modeling language (e.g. UML), the model you get captures such value in a precise, complete, non ambiguous way. And you are also sure that the running (generated) code is totally consistent with the model. Moreover, newer versions of the platform’s code generator can later turn the same model into a new executable version of the system with significant improvements (stability, performance, architectual resilience).
In my view, in the future the code will be less and less considered an asset. The model will.
Well said Antonio.
Thanks Jordi for the good conversation around this topic. It’s really interesting.
There are new low-code platforms that have come out in the market lately and their pricing models have evolved. For example, AppSheet.com was recently acquired by Google to replace their low-code platform called App Maker. Their pricing model is pretty decent for indie developers. Their free layer of subscription lets you use all functionalities and test it with up to 10 users and after that you can upgrade to a 5 USD/month. The way I see it is that for an initial idea validation phase 10 users should be enough and once you get that inital validation the next users should be those that are willing to pay for a half baked app that solves their problem (early adopters). If you can’t get paying customers early on then it should be an indication that you might be solving a problem that it’s not too painful for people to pay for and maybe you should pivot.
Anyways, thanks again. I had a good read of your post and everyone’s comments as well
Hi Jorge, there is an Brazilian low-code platform Cronapp that has a business model oriented with an option of on demand use. Try it at http://www.cronapp.io