Performance, Stability, Costs. How Does It Look in No-Code/Low-Code?

Hi, This is Kamil Tarczynski. I'd like to welcome you to another episode of our JUST NO-CODE podcast. Today we're going to talk about very important topics concerning no-code, around which a lot of questions, insinuations, understatements or uncertainties very often revolve. The topics we will discuss today are performance, stability and cost. These are very important issues that de facto everyone wants to have taken care of and wants to know the answers to how it is de facto with this no-code. Is it efficient, Can we support hundreds of thousands of users on it? Is it stable? What costs does it carry? And today that's what we're going to talk about. At the outset, I just want to point out that today's episode will be such, let's say, a collection of our experiences or a reference such averaging and finding a common denominator with regard to four platforms that we simply use and with which we also have the most experience. These platforms are Bubble.io, Xano, Webflow and FlutterFlow where it will be necessary, of course.

Will there be a need to do so, because the platforms will differ significantly just by this common denominator. It is not possible and to that common denominator is what I will, of course, try to point out and tell you exactly about it.

On the other hand, the other very important issue is that if we talk about the performance, stability or cost of a particular platform, this is a very important issue for us, because we want to build a production solution that works for many users. We know that we want it to scale so that we don't have to rewrite it right away or migrate it to another no-code solution or whatever. That we should always tailor our requirements. That is, we should verbalize at the very beginning what our needs are, what platform is able to cover those needs and also to what extent, because, for example, Bubble is a very flexible platform or Xano is a very flexible platform, there are also platforms on the no-code market that no longer offer such flexibility, and unfortunately we won't do anything about it. And it will be a good solution to build only an MVP for a few dozen users. So without further ado, let's start with performance. How this de facto performance in no codzie works. Very often this question runs us from our customers or traditional developers.

The code is not so efficient, because if you don't write the code yourself, well it can't work so super And of course in some respect to some extent I agree with that.

Of course, that if we have a team of developers who operate the code one hundred percent, and this code forces down to every single line, dot and so on, it will be optimized from A to Z, then of course it will be much more efficient than such code that is generated by any platform, because it has been released, optimized in every possible respect and for this particular, single solution. You have to remember that code platforms are general-purpose platforms. It's not that a no-code platform is good for building fintech, or some social media, or medtech, or something else. They are general-purpose solutions that are supposed to allow us to build general or miscellaneous solutions as well. Because of that, their code is also optimized, but in terms of general performance or general efficiency, not in terms of one particular one that we want to build. And it may turn out that as the whole platform goes super, great and extra, unfortunately some one function that we have thought of, not so much anymore, because unfortunately on this platform it will function a little bit differently than in the traditional approach.

Of course, this is not a hindrance, because we can build various workarounds, we can use some third-party solutions, we can build ourselves an API externally to get around this, on no cod platforms we can simply add a piece of our own code, which will then process this data as we wish. Well, but yes, in this case it is known that this code is not perfectly optimized, while it is optimized as I said, for tasks in general and in this respect it is perfectly optimized, because the platform. More and more people are using it. Bubble alone at this point is already being used by almost 3 million people and that's developers alone who are building their solutions on this platform. So Bubble and the makers of other no cod platforms make sure that this performance is at the highest possible level, because they work with big companies, they work with medium-sized companies. And if they didn't offer that performance at a high enough level, at a high enough level, they would just lose customers. That's why, of course, underneath this code is generated it's still there, it's optimized a little bit differently, well it works in a completely different way.

It is also designed for other solutions. However, in the case of, for example, FlutterFlow here, we just have to give this exclamation mark or asterisk next to this solution, because FlutterFlow creates a native mobile solution, where the native application will generally be optimal, as long as the backend allows it, it will work in a fast way. Plus FlutterFlow allows us to rummage through the no-code and optimize it from A to Z, download, change, adjust or optimize it. So here we have a little more room for maneuver and it's also a completely different case. On the other hand, you also have to keep in mind that when it comes to performance or scaling of these solutions, every no-code platform is currently running on Bubble cloud e.g. on AWS, Xano on Google Cloud, etc. etc. Each solution uses something different. Again, except for FlutterFlow, which builds us a mobile application, that is the Frontend. Only the Backend we have to have from somewhere else. It is already up to us where exactly it will be from.

On the other hand, if we are just talking about whether these solutions scale, whether they are efficient, then by all means they are. And again, let's compare. Let's compare it to the traditional approach. The traditional approach we have to have a team of DevOps or other people to take care of that, to build for us the infrastructure on which our application will go.

Because, of course, it's one thing to build, to write the application code, but it's quite another to put it on the infrastructure, which will also take place processing efficiently how networking will work in such a solution, how security will be built, etc. etc. This is the time we need to spend on building our solution, etc. And which also has to be done well. In no-code it looks completely different, because in no-code these solutions of ours already use a ready-made infrastructure. We get such a, you know, one packaged product, where we don't worry about the infrastructure, which stands underneath, because it's scalable, because it stands on the cloud, because it's customized for this solution. There, all these security rules etc. are already properly implemented. If anyone wants to get acquainted with this, how exactly it works, I would of course refer you to the documentation of the provider in question, where we can read all about it. Well, and we don't really have to worry about it anymore.

We need to take care of the performance at the level of the application itself, not the infrastructure, because the performance at the level of the infrastructure is already at a high enough level. Because it's as I said on AWS, it's still configured there somewhere, we can get familiar with it, like again.

Of course, this is tailored to that particular platform, but it works great in most cases. If, again, we have some special function that the platform doesn't support well, and so on. As I said before, we can take it out ourselves somewhere outside, so in this respect, again here we have some automation, we have some customization, which of course has its advantages. If, for example, like banks, we have some special regulations, some special security regulations or large corporations, we have two choices. Of course, either we have to put up our own application and our own infrastructure, because otherwise it's impossible. On the other hand, we can use no cod applications, because most of them allow us to put these applications on dedicated servers. That is, we can use such a dedicated plan, where simply the server will be ours in our cloud, or even on our on premise, that is, locally placed, and there the company will deploy its solution so that we can use it and put our applications on it.

So as you can see there are many ways. We can approach this performance here at the infrastructure level in different ways, and it depends, of course, on what our company or our client's exact requirements are.

Well, and so to kind of sum up this topic of performance, where we talked about how de facto no code looks like how it works underneath, where we know of course that this code is certainly not as perfect as the cat's mouthed, where of course mouthed, which also costs its own, because things like mouthed take the most time. It is our main task to make sure that our application is actually efficient. If the manufacturer of the no cod platform has already taken care of the infrastructure to be efficient, then our task is left to take care of the performance of the application. Because if the code has even been optimized as much as it could have been optimized, although all the time this optimization of the code is taking place, all the time the no-code platform producers are optimizing something, changing something, adjusting something, etc. etc. This is us as application developers. Our job is to build all the workflow or build the user interface in such a way that this application is efficient. That is, for example, on the front end.

Of course, we avoid duplication of elements, so that there are not too many elements on one page, so that the server can easily process these requests, so that these pages are not heavy, so that it does not download a lot of information from the servers, that is, not millions of records or thousands of records at once, where it is known that this is a problem.

So we have to make sure that this frontend is efficient, so-called lightweight, so that it downloads quickly. On the other hand, of course, all these workflows of ours, how they work, how the database architecture will be set up, won't these records be too heavy? Will the database not be too heavy, Will it be built in a performative way? Will all the workflows be built in a performative way, Won't we be doing too much? Is this already an issue that we as developers need to take care of in the application in order for it to be efficient. In my personal opinion, in this day and age, where we really have access to super infrastructure, where most applications are not likely to be super extra mega complex applications that are designed to do very complex solutions, then at this point we are easily able to build most applications using no-code or low-code, simply optimizing our work accordingly. What about stability if this performance is so great and it works, then how is the stability? Well stability will be a bit hooked on the topic of performance for the reason that.

We said to each other earlier that these solutions stand in the cloud or at our place somewhere. So what is Stable about? Stability can be again at the infrastructure level or at the code level. That is, does our code have any vulnerabilities, bugs or something like that, which could cause the application to crash, not be stable, break or whatever? Let's start with the infrastructure part, because it will just be shorter. If Bubble, Xano, Flutter, Flutter not sorry, if Bubble, Xano and Webflow stand on solutions on Google Cloud. Do you need just that their stability is based on these solutions. Of course, they still have some code that is deployed on that infrastructure and so on. On the other hand, from an infrastructure point of view, we don't have to worry about that. As long as AWS works, our solutions or any other cloud will work. On the other hand, you can raise the subject of this ok, but I have no certainty that Bubble or Flutter or Xano or Webflow is written in an optimal way, without bugs and so on.

Of course we don't have such certainty, but that's also why these vendors provide their status page and so on, to see how often these applications possibly crash.

I will reveal to you that Bubble in the last month had an availability of 99.99%, so they have at the same level as the public cloud stability. Plus isn't that code blowing up on us? There we have all this information about if there was even a failure somewhere along the way, we can read about it, what was it about? Whether it was an AWS audit, whether it was some kind of audit, whether it was on the side of a particular vendor of a particular platform. Then we can just reevaluate for ourselves internally. OK. Is this platform stable in terms of its own infrastructure and code, or not? Well, and now if we've got this infrastructure topic behind us, now let's move on to this topic of code, that is, whether the code that these platforms offer, that we can use, is stable. Well, and here again I will return to the topic of precisely the number of people who use these solutions. If we build in some software house or in-house team, we build some solution, how many people this solution this code will test?

5 10 is a super result. Of course, we can still let the tests go to that.

Automating to make sure the whole thing is stable. What should we do? On the other hand, imagine that, as I said before, from such a Bubble there are 2 million developers alone, more than 700. They put up their applications. Each of these developers may have several apps, even suppose they have one. Well, and each of these apps is used by some user, even if only one. That's at this point we have almost 5 million users who are examining this code on a daily basis, which is provided by e.g. Bubble e.g. Webflow or e.g. Xano, which is being examined all the time. If there's something wrong with it, or it causes some crashes or whatever, it's reported right away to the platform developer and fixed in some time. One thing is known I won't lie, they are fixed faster, others slower, but they are fixed. If this stability was not there, if these platforms did not offer this stability, did not offer all these solutions, well at this point they would lose users due to the fact that there would simply be some problem with their performance.

So as you can see, this performance or test stability work together, they are based on the same de facto foundations, on the same foundations.

One draws from the other. And they mesh nicely together. So in my opinion when it comes to stability there shouldn't be the slightest problem either. Anyway, you can check this for yourself by going to our case study, checking our applications or simply checking the availability statistics of the solutions. Finally, I would like to talk about this very topic, which is of interest to many, because it helps to plan business in a certain way, to predict what we will in fact face in this business, that is, the cost of everything. Of course, it all depends on the platform and what kind of platform we want to build, how many users we are going to support, or how complex a workflow we are going to build. For the reason that it simply has an impact on server resources. Bubble's platform for it. Xano and Webflow offer us subscriptions, and those subscriptions are that we buy some functionality plus some server resources. They are not directly specified, that we buy 4 CPUs and so on, because that doesn't tell us much to the end, because each of the vendors of these platforms has gone a little bit their own, individual, price list, which allows us to determine how much we will de facto consume these resources.

Bubble server provides a calculator in which we can calculate these costs for ourselves. If we build ourselves a test application, there we have calculations of the so-called workflow units, which help us reevaluate how much a given action costs these workflow units, thanks to which we are also able to better optimize our application, because we can see what is the most resource-intensive in our application, look at it and from some angle, try to optimize it. But going back to these subscriptions, each of these platforms is cloud-based, so it also follows this concept a little bit. We can buy such basic plans, which give us some server resource at some fixed fee, that is, at some specific price. Some platforms allow us, like Bubble for example, to buy server capacity, so that we are not blocked when, for example, many users enter at once. If the server becomes very loaded, so as not to block, timeout it, not to cause some other problems, then Bubble automatically selects the resources for us, but of course you also pay for it.

It's called a subscription Pay as you Go That is, as long as you use or use more you just pay for what you actually use.

A slightly different conversation is in the case of FlutterFlow, where FlutterFlow de facto does not host our application in any way, so there we pay for access to the editor itself, where we can build our application and put it in the stores, where the backend is also hosted somewhere else. And of course, this is one side of the coin. This is the public side of the coin, I would call it. Where we have access to these traditional subscriptions or just these Pay as you Go subscriptions, where we pay de facto for the use of the server, so that's also again within our control. Going back to performance is to build this application optimally. So that these workflows don't eat a lot of these server units, so that they don't clog up the server, because that way we'll just pay less. We will be able to serve more users or our clients at the same price. On the other hand, of course, I also mentioned to you that these solutions can. Be placed on our servers or our cloud.

Then we already enter the so-called individual price lists. Enterprise price lists, where it is directly with the manufacturer of a given platform that we determine how much a given service will cost and how we will pay for it.

Of course there are price lists out there, we know those prices, but we don't share them specifically in this episode, because there are always individual calculations or negotiations anyway about how the solution will work, what it will include, how much it will cost, etc. etc. So de facto we get some server resources, which we also have to take care of. So as you can see cost, stability, performance all go together and give us one set that we should take care of. And here to sum up today's episode, what I want to emphasize very, very strongly is that it is mainly up to us whether our no-code, low-code application will be efficient, stable and what costs it will carry. For the reason that if we design these workflows or databases badly, we will load the server unnecessarily, we will de facto eat more of its resources. If we eat more of its resources, the application may crash, we will pay more for it, so we lose stability and we lose money.

What it all boils down to is that we should always approach the application in a thoughtful, planned way, so that we can be sure that we are doing it in an optimal way.

And here was a great saying that Abraham Lincoln once reportedly said that if I get 10 days to cut down a tree, I will spend 8 days sharpening my saw so that it is properly sharpened. I worked a little, it didn't last perfectly. Yes, but it captures the idea of just how we should approach the matter of building applications in no-code low-code and traditional approaches so that they are efficient, stable and don't cost us much. That's it from me for today. See you there!

‍