From MVP to Complex Applications: What is No-Code/Low-Code. We explain and debunk myths!

Hi, My name is Kamil Tarczynski and I welcome you to the first episode of the Just No-Code series, in which we tell you what this technology is and how you can use it in your own businesses. Today's topic I'd like to focus on, which I'd like to tell you a little bit about, will be a very basic topic, that is, explaining what no-code / low-code is in general and what we can use it for, and whether it's only suitable for creating MVPs. So let's start from the very beginning. What is no-code? As some of you may be familiar with what programming is, programming is about writing lines of code and deploying that uploading it to some server so that this application is available, for example, on the web or on your phone or wherever, so that our users or our employees, whoever will be our users, can use this application. And of course, the programming that we comprehend, which however we understand or have an idea of what it looks like, is no longer some evolutionary stage of what programming looked like in history.

‍

Of course, programming also like any technology evolves over time. Programming in the early years, when we started working with computers, when computers were, let's say, discovered in big quotes and when people started working with them, they also had to program them.

‍

This programming started with so-called punched cards. We had such special cards, in which we made holes, so that the computer knew what zero-one instructions to process. Then we had assembler programming, for example, which is a bit more higher level, more processing of what is binary code, a language more understandable to humans. Later this assembler evolved into something even higher, these low-level programming languages. Later, it all evolved into these high level programming languages, high level programming languages. These are the languages we know today Java, JavaScript, C++, etc. Where this code for humans is even more understandable, even more readable, is written in a more human language. Because, as you know, the computer in no way understands what we humans tell it, what we click on, what we do etc. It's all more about us giving some instructions to the computer, giving it some instructions, they are processed somewhere, and at the end they are processed into these zeros and ones. Well, and heading into this no-code is the next stage in the evolution of programming.

‍

Why?

‍

That's because in no-code we don't create, as the name suggests, with code. No-code means no code, or low-code. Low-code. Here, to a large extent, our programming is based on so-called visual programming, or what we see. We have interfaces, let's say, such white sheets of paper in no-code editors, on which we place page elements. This is where we start the application. Each one is also, as you know, divided into frontend, is divided into backend and frontend. This is what the user sees. The backend, on the other hand, is what happens on the server side, which is everything that is invisible to us, but where mostly all the magic of the application happens. Storing data, processing it properly, creating results, outputting those results to the frontend, and so on. So, In no-code, the user interface is just created by so-called WYSIWYG, or What You See Is What You Get, that is, by moving items from a list onto this white sheet of paper.

‍

That is, we have this white sheet of paper. We imagine what we want our application to look like, that here it will have a menu and here below it will have some kind of login form.

‍

For example, we take individual elements, e.g. some groups, some shapes, some other inputs, that is just those fields where you always enter your email address or password or some other information. We place buttons here. And in this way we have created the frontend, that is, what the user sees. The advantage of this approach is that it is, of course, much more readable for us. We can immediately, tangibly see what we are creating. We don't need to imagine it, we don't need to write hundreds of lines of code to create this interface and we don't need to debug it later. I mean, we debug it, but we don't have to fire it up, we don't have to process it to see what it looks like. We just see it right away at the editor level, so it's much more simply readable, so it's much faster to create. On the other hand, how does the backend programming look like in no-code? In no-code the backend is created in such a way that everything that is supposed to happen on the frontend, but is supposed to be followed by some action, when you click on, for example, a button, we program it in such a way that we select, for example, "Click on the button".

‍

some button element and we say application: We have this special place in the editor where we say: oK, if I click the button I would like something to happen. The editor opens up for us and there we have step by step, information flows it's called workflows, workflows. And in these workflows we select that in step one this should happen, in step two this should happen, and in step three this should happen. And of course, here it is already up to us what will happen there. For example, if returning to the registration or login form, we would put an action under the button, which would have the task of logging in or registering the user. Well, and we have a special step in such an editor that we say register user. OK, we need to indicate where this data should come from. Of course, they have to come from these inputs, which have some names, which also have to take some value, if the user enters these values there. Well, and from these inputs these values are to be taken stored in our database.

‍

And at the end, if the registration was successful, the user should be redirected somewhere.

‍

For those of you who are responsible for creating processes in companies or that sort of thing, it will be a bit like BPMN notation, that is, those notations where we write down step by step what is supposed to happen, for what actor, what are the conditions for performing those actions, and so on. Itd. So, as you can see, in no-code we create everything for ourselves precisely with the help of these visual elements, which for humans are readable from A to Z, because they are expressed first of all in human vocabulary. Because the whole action doesn't require programming the whole action under the button, it doesn't require knowing the semantics of a particular programming language, it's just when button x is clicked. That is, when button X is clicked, the registration is supposed to work, the redirection is supposed to work and the display of an alert about successful registration or login, for example, is supposed to work. This simply makes it much more readable. And this is no-code. Here we use such predefined elements, which are offered to us by the manufacturers of a given platform.

‍

Such, let's say, Lego blocks from which we create our entire application. Of course, we have a variety of Lego bricks available, and just like Lego bricks, having a variety of different bricks we can create a variety of different builds.

‍

And that's what we're about to get to, We're about to talk to each other right now about these beliefs around no-code and what we can build with this no-code. So. In general: what is low-code, then? If no-code is the part of programming where we create everything for ourselves without using code just from these predefined blocks, then what is low-code. Low-code for that looks a bit like no-code. We also have these predefined blocks, predefined elements, with which we can build ourselves a whole application. Well, but here we have one very serious limitation. If we use such a platform, which is strictly no-code, it means that we can only use just these predefined blocks. That is, we also have some limitations that are based on the capabilities of a given platform. There hasn't been such a manufacturer yet and probably won't be for a long time. If ever such a manufacturer of no-code platforms will appear, which will define all available elements of the world. Impossible. In my opinion. At least for this moment.

‍

And will offer them to us in a single platform, so that we can just do everything that we rzewilly like, without using a single line of code.

‍

That's why there's also a low-code approach, and it's that the manufacturers leave us a little gate. With which on the frontend or backend or both we can add our own code. That is, at this point we can build ourselves three quarters of the platform without using a single line of code. So that the creation of this application, this automation or whatever, will just be much faster, more efficient, more understandable for people. Because if we know that the Platform has some limitations and doesn't offer something natively, then we have this little gateway through which we will be able to build or make for ourselves that functionality that we lack and integrate with that Platform. Of course, no-code platforms, just like low-code platforms, also offer us very often the possibility to connect to an API. This is such a special interface through which we can connect to other third-party solutions, so we can still extend these platform functionalities very widely, but I think this is a topic for a separate, completely different episode already, so let me not touch on it at this point.

‍

So we already know what a no-code platform is, we know what a low-code platform is, and how they differ from this traditional approach to programming.

‍

This is simply the next stage of evolution, with which it is much easier for us to program these applications, because they are What You See Is What You Get is a great term. That is, what you see is what you get, making this programming much faster, much more efficient in terms of time usage. On the other hand, it also brings with it certain, as I already mentioned, for example, limitations or certain needs related to the fact that we have to think about these platforms a little differently than such a traditional approach to programming. However, the exact differences in how these approaches differ, what we need to think about, what we need to keep in mind, is also a topic we will cover in future episodes of this podcast. Today, however, I would like to focus on what we said a little bit at the beginning, which is precisely these misconceptions about no-code / low-code and what they stem from. A great many people believe precisely that no-code platforms, by virtue of the fact that they are some kind of already predefined elements, these very lego blocks or closed platforms, that they have very low capabilities.

‍

And, of course, until a good few years ago, that might have been true.

‍

These platforms really didn't have very broad applications, you could create some simple application or automation prototypes in them, while at this point they are already very mature products. Manufacturers such as Microsoft, Google also SAP, create their own no-code platforms, such as PowerApps, AppSheet or AppGyver, which allow us to create very cool products. These are still sometimes not platforms that allow us to do everything, of course, but they already allow us to do a lot. We also have platforms like Bubble.io, which we use most often, or Flutterflow or Xano. These are already very advanced products, very mature platforms Bubble, for example, is already twelve years on the market, which allow us to actually even I would be tempted to say create unlimited, unconstrained in any way. Why? Because, as I mentioned, these platforms are very mature, and secondly, each of these platforms allows us to add our own code. That is, even if that platform doesn't offer something, we can still add that code for ourselves there.

‍

Good. On the other hand, where do these beliefs come from?

‍

What are they like? First of all, they are that these platforms are limited, that they don't scale, which is also obviously not true, because each of these platforms, what they set themselves to do is to be able to scale. How do these platforms scale, how do they do it? Each of these platforms, of course, is some kind of closed infrastructure, where we as users, as application developers, can't pick and choose what's under there. We already get a ready-made platform, ready-made hosting, on which these applications of ours are fired up. This, of course, has gigantic advantages, such that if we want to build, focus on building products, rather than choosing the technology stack, what these platforms will stand on, then in most cases we are more concerned with proving the value in the product, rather than choosing what technology it will stand on. Because as long as the technology works and does its job, as long as it's good, these platforms underneath also stand on the cloud.

‍

In the case of Bubble, it is AWS.

‍

In the case of Google, of course, it is Google. In the case of the Xano backend platform, it's also *Google, so here all the platforms offer us cloud hosting. That is, they also scale. Of course, this hosting looks a little different. We don't influence it, it's predefined somewhere underneath, and we get the corresponding price list from the manufacturer, from the manufacturers of these platforms, where we can choose for ourselves these price lists, where we can indicate that ok, we want to start with some small plan, which will cost there $29 per month, and then as our application scales, this plan will also grow. So I think this is where this misconception about not being able to scale can be put between fairy tales. The Bubble.io platform, for example, claims that it is seamlessly able to support half a million users per month in the app. Of course, I would look at this with a bit of a pinch of salt due to the fact that it always depends on what the platform does, what functions it performs, how much it loads the servers, not the user's device.

‍

But here we are getting into such very heavily technical details, which are rather irrelevant to us at this point.

‍

Another such misconception about these platforms is their security and relability, that is, how these platforms, let's say, are resilient to failures or that kind of thing. Well, and maybe up until a few years ago it actually might have had some meaning, some sense, these two arguments. However, in the case of, you know, platforms such as those developed by Microsoft or by Google, well, you know that this security is at the highest possible level. These are typically enterprise-type solutions, a solution like Xano has a great many certifications attesting to their security, to how they store their data. It's also one of the platforms that we use on a daily basis for backend development. The Bubble.io platform also here offers very many certifications that attest to its security, the fact that penetration testing of this platform is done there regularly so that it provides the highest possible security. And each of these platforms is used by small and medium-sized and enterprise companies. And then there's the relability, which is how fault-tolerant these platforms are.

‍

Now imagine a great example here: you develop applications in a traditional approach.

‍

You create it inhouse or with the help of a software house well and this application, of course this code that is written has to be tested by someone how many people will test this application before you release it live. Two, three, five, maybe ten. Each of these components will be tested somehow, of course. Each software house offers appropriate Quality Assurance services, which are just to test that code, to test the stability of that application, the performance and so on. We also have test automates, which automate these processes, test how this application works, whether it is indeed resistant to various types of failures. And now let's compare it to a platform like Bubble. Platforms like PowerApps, platforms like Xano, where every one of these components that this app offers is used on a daily basis, by millions of users. Millions of users. Bubble.io, for example, boasts that at this point it already has more than, as I recall, two million users of its platform. That is, people who create applications on that platform.

‍

These users have their users in apps. So each of the building blocks from which this app is built is tested by millions of users per month, millions of users per month.

‍

If the slightest bug happens there, in that particular block on one of these platforms. Believe me it is caught and patched very quickly, because it would cause millions of applications to simply not work on a daily basis they would not be stable. And, of course, this doesn't mean that there are no possibilities of failures on such platforms, because they still occur there, but they rely more on the fact that it's us who incorrectly design this flow of information or this communication between the backend and the frontend, so that simply somewhere at this stage an error will occur, but not at the stage of the very component from which our application is built. So, as you can see, in conclusion there are a great many misconceptions about no-code, which in my opinion in this day and age at this moment are no longer true in any way. We will now talk to each other, then, about this most important misconception about no-code / low-code, that this approach is suitable only for and only for building MVPs, that is, such first test versions of the application, such versions with which we want to go, explore the market, research, show them among friends, among some larger crowd of users.

‍

But it's still not that you know, a big Enterprise-esque product that has a lot of functionality, a big giant dataset, etc. Itd. Is this true at this point? The answer will be short. Of course, it is totally not true these days. Why? Because, as I already mentioned, first of all, these platforms offer very high performance, nothing different from the traditional approach, which, by the way, you can check in the very many tests of the available platforms. You can test them yourself, see how it works, you can check our case study, you can check yourself the case studies of other no-code agencies that create such solutions. Just see live, click through these applications. How do they work? Where are the thousands, tens of thousands of users? How do these applications work on a daily basis? You will also find plenty of articles by the manufacturers of these platforms, where there are just comparisons of this performance. Believe, by the way, that manufacturers like Microsoft, Bubble, Xano, Google, for them performance is an absolute top priority.

‍

You have to take into account that the manufacturers of no-code platforms fought for a very long time precisely against this belief that they are only suitable for this and that this performance is at a low level, which made it a top priority for them, too, to prove that this is not the case. Another thing that dispels a bit of this myth that it's only suitable for building MVPs is how advanced features it currently offers. Really at this point, where we have a lot of these predefined elements, we have really gigantic possibilities for filtering, processing, showing data, building really beautiful frontend interfaces for the user, building very complex flows of this information, workflows, integrations via either APIs or custom code. It's at this point that we're really only limited by our imagination and our knowledge of these solutions and our understanding of how they work, to build these solutions in a way that will give us the right performance for these solutions, rather than being limited simply by the sheer sheer belief that these solutions are not suitable for this.

‍

Yes, they are suitable, as these companies are proving, where you can read plenty of case studies and companies that already have hundreds of thousands of users, tens of thousands of users, and even corporations are using this as an internal or external tool to deliver gigantic value to their users. And why no-code, in my opinion, is a much better solution when it comes to building MVPs, but also much better when it comes to building already such complex platforms.

‍

First of all, because, as you've already heard, with this drag and drop, WYSWIG approach, of this interface, we speed up the development of applications much, much faster. Some people talk about up to 10 times acceleration. However, I would rather not talk about such a gigantic acceleration for the reason that if we want to take care of the performance, the quality of this application, there are still a lot of processes around which no-code will not take care of, that is, proper design, proper quality assurance, proper preparation for the project, proper documentation, proper understanding, design of the whole application only this development that we speed up. On the other hand, I can certainly say that development is able to speed up at least twice, three times compared to the traditional approach. And this is a gigantic advantage that very many companies will see as this main advantage of this approach. And, of course, still if these platforms don't offer everything, we will have to add this own code. But remember only such a very small part, and we will not have to build the whole platform.

‍

So it's good now, if at this point we have already talked through. What is this no-code?

‍

How can it be used? What is low-code? A very briefly overplayed. How this application design approach differs from the traditional one, and what are the misconceptions and why we think they are misconceptions. Not only according to us, by the way. We also partitioned whether no-code is only for MVPs. Why some people think so and why we think it is not. Let's try to briefly answer the question of what kind of things, then, we can build with this no-code / low-code. In fact, do I have a good answer to this question? I have a very simple answer to this question. In fact, what we want to build depends 100 percent on us. With no-code we can build process automation, we can build web applications, we can build mobile applications, native mobile applications based on React or Flutter. We can also build browser extensions, we can build the backend itself, we can build very powerful websites using a tool like Webflow, for example. It's a bit like WordPress 2.0, the kind of WordPress of our time.

‍

So really within those individual elements already, whether it's going to be automation, whether it's going to be web, whether it's going to be mobile, whether it's going to be anything else just for example.

‍

browser extension, or the backend itself, then our possibilities are endless, and it will really depend on us what exactly we want to build. For example, if I want to build a web-based CRM for which I will want to develop an application, can I do it with no-code? Yes, as much as possible, yes. You will find very many examples of such applications on the Internet. Some better, some worse, but you will find them. You will see that they function. If you want to build a dating app like Tinder, which will be exclusively for mobile devices and it will be a native app. Will it be possible? As much as possible, yes. If you want to build a video conferencing application that will be a web and mobile application, will it be possible? As much as possible, yes. If you are a frontend specialist, you know how to build the frontend, but about the backend you have no idea, and you would like to use some simple tool that also step by step in a way that is clear to you, to make the backend enable you to create it, is it possible?

‍

Yes. As much as possible yes, because the frontend clicks out for yourself, the backend clicks out for yourself in Xano, for example.

‍

Of course, I'm trivializing a little bit by saying you're going to click out, because you still need some knowledge, to know how it all works, but you're able to do it and this frontend will integrate with this solution, because Xano will expose you to the appropriate endpoints for methods that you build yourself, or endpoints that you build yourself. So really the subject of what we're able to build, how advanced it's going to be, it's going to depend solely on you, on your approach and really how familiar you are with the subject and the approach. You have to remember that it's just like with any little solution. The further into the woods you go, the more trees there are. Just like in traditional programming, it's very easy for anyone to learn how to write the first program that we write in probably every approach, which is Hello world, or how to display Hello world in the console. The same is true in no-code. You will be able to build the first applications in a very fast, traditional way.

‍

They will be simple, they will be primitive. These interfaces will be primitive, but it will show you what power is in these platforms.

‍

You will see that indeed the multitude of features that these platforms offer, or the multitude of options of what you can build there, what to integrate with, etc. is really infinite, and in fact our knowledge and imagination only limits us in what we can build with these platforms. In summary, no-code / low-code is the next stage in the evolution of programming, with which we can build web applications, native mobile, automation, backend or browser extensions in a graphical, visual way. No-code is suitable for building MVP prototypes, but it is also 100% suitable for building large, complex solutions for gigantic numbers of users with gigantic amounts of data that we will process. No-code is already a very mature approach to software development, with the help of which we can create just those previously mentioned things. And it is no longer just a toy to be trivialized. Microsoft and Gartner claim, or rather, to be more specific, Gartner claims that in the year 24 as much as 65% of the world's applications will be developed precisely using the no-code / low-code approach.

‍

Microsoft, on the other hand, goes even further and claims that 450 million apps out of the 500 million apps created by 2025 will be created using just no-code.

‍

Does this mean that the work of programmers will either become unnecessary, or programmers will become unnecessary? Of course not, that's totally not what it's about. Programmers will still be needed, programmers do a super job, but the focus will simply shift a bit. Programmers will be able to focus on creating technologies that have very, very such unique IP. It's Intellectual Property, which no-code at this point can't handle. It can't create, for example, something like it is now, now GPT or things like that, which you know need really very complicated algorithms, very complicated things and very unique things that are hard to replicate or copy. That's where most of the developers will move. And most of the applications will just be able to be created using this no-code / low-code approach. Because what programmer, who among us anyway, likes to create repetitive things? Every app offers a login or registration screen. Every application offers some list of things that we create in it. And these are things where you don't need to reinvent the wheel, and it's unlikely anyone wants to program the same thing for the hundredth time.

‍

Therefore, this burden of creating these applications in our opinion will simply shift a bit.

‍

That's it from me in today's episode. I hope you found it interesting and that I was able to tell you a little bit about what no-code is, what low-code is, what its uses are, whether it's only suitable for MVPs and that it will give you a little bit of knowledge on the subject. That's it from me for today. Thanks. Hi!

‍