.svg)
00:00 - Start
00:20 - Introduction
01:17 - Platform categorization
01:45 - Automations
13:55 - Web development
22:30 - mobile development
29:30 - Backend
37:00 - Other platforms
39:45 - Summary
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, or rather, do a little overview of the no code and low code tools and platforms. What exactly does that mean? We're going to divide the no code and low code tools into categories that we can cover with these tools, that with these tools we can make easier for ourselves, automate, etc. And in each of these categories, I will point out to you the areas: Firstly what is this category good for? Secondly, I will give you some use examples, to give you a better idea of how you can actually use the service of a given platform. I will also point out the most popular platforms you can focus on, with which you can get acquainted. In today's episode, the categories I'd like to cover of these no code, low code tools for areas such as Web Development, Mobile Development, Backend Development and a whole bag of other applications, which we'll also discuss in part.
So without further ado, I invite you to this episode. Great! So what categories do we have, and how do these categories differ from each other? We'll tell you about them briefly. We'll start with automation and go through all the others.
What actually are automations? Automations, as the name suggests, allow us to automate certain processes, digitize certain processes as well. If we have different processes in our company, because every company should have these processes. But this is already more of a business topic than a technological one, so I won't touch on it today. It's every company that relies on some processes. If we sell a product, onboarding a customer to that product is some kind of process. If we run finances in our company, well, running those finances, receiving invoices, sending invoices, etc. This is some kind of process. Mostly it is the case that all these processes are of course carried out by people, we have them written down somehow, everyone is more or less familiar with them. As it happens in a company. Well, and each person also in his own way, let's say, these processes are implemented. This means that some inaccuracies always creep in there, some untimeliness creeps in there, some simply human behavior or human tinctures creep in there, which make these processes not always work perfectly, not always work in time, etc.
etc.
What can we generally do about it? If we are currently using some SaaS tools (SaaS stands for Software-as-a-Service), and most companies are using the likes of Office 365, Google Workspace, some CRM, ERP type programs. Invoicing programs, accounting programs like Comarch, etc. etc. It is all these tools, or rather most of them, that issue their so-called End Points, stubs with which we can connect to them. What does this de facto mean? It de facto means that most of such processes that are repetitive, that we can draw out for ourselves somehow on a piece of paper, that we hand over to people to execute, we can automate to a very large extent. If we can automate them, it means that of course we eliminate errors to a significant degree, we eliminate timeliness to a significant degree, and so on and so forth. Well, because a robot will be responsible for it, let's say in quotes simply a robot, if a robot will be responsible for it, some kind of automaton, which will be supposed to do something on a given day, to do something will be triggered by something, that is, triggered by some activity of ours, or by the arrival of an email or anything else, we will talk about examples in a moment.
Well, then he is supposed to perform some consecutive actions. He is supposed to do something there, for example. This gives a significant advantage to the company that, firstly, we can relieve people from doing repetitive, boring things that are not de facto value-added to the company, are not value-added to the service. Well, but they are repetitive and could easily be done by a robot. What does that mean? It means that it will be able to do these things at the same time, or much faster than a human can do. And we can delegate our employee's to more essential tasks that, at this point, to take care of tasks the robot machine will not yet be able to perform. What could these tasks be? What kinds of things can we automate for ourselves? There are, of course, simple things that we can automate, as well as more complicated ones, and these complicated scenarios will be hard to describe, well, because, you know, it already depends on some more specific use of the time of a given company and so on.
I may not go deep, but I will try to outline for you what kind of automation we can certainly do.
And so let's assume. Our company, like any company anyway, receives invoices from customers. It receives invoices from our suppliers, our platforms. Well, and these invoices we as people have to send to accounting, we have to put them in some given folder, mark them as posted or whatever. Well, and now let's imagine that we have a dedicated folder, into which all invoices fall under the title of, for example, invoices @ mycompany.co.uk . Well, and we create an automaton for ourselves, that if an invoice falls into this email, an email with an invoice comes in, well, something is supposed to happen, and what can happen? We can combine this service with Google Drive, for example. Yes, If it comes to our Gmail or to our Office, then we connect that service to Google Drive, or to SharePoint, or to Box, or to any other office service where we keep our documents. Or it can also be our in-house folder of some kind, of course.
We can also integrate this with our internal tools.
Well, we tell this attachment with this invoice to send there to that particular folder. If it fell in February, then it should be moved to the folder, which is in the 2023.02 folder, and that's where the file will be placed. If the file falls in there, we want it to be sent immediately to our accounting program or to our accountant, so that she can do something with it. And if something happens there again, we want this document to be marked as, for example, posted. It's supposed to be closed, or its name is supposed to be changed, that we know that this document has just undergone this automation, it's been sent to the right place, and at the very end we get an email Hey, this document has been sent to accounting, etc. etc. so, as you can see, this is such simple automation that takes off our responsibility to do the so very thankless task of just categorizing these invoices, searching them, putting them in the right place, sending them to the right people.
This, for example, is such one example of automation. Of course, very often we will want to automate for ourselves the running of our projects, for example.
if we have some tasks in ClickUp or in Jira, or in any other tool with which we run our projects, we can also build such automation there. That is, for example, if a task has fallen into a certain status, or has been assigned to a certain person, or someone has sent us a new notification from our clients, well, something is supposed to happen with this task. For example, it should be assigned to the appropriate person, the appropriate comment should be added. And a return e-mail should be sent to our client with a signature Thank you for this notification. These are, of course, such very simple examples of these automations that, first of all, improve this User Experience, if these are automations regarding how our customers interact with us or most simply relieving people in our company of what they would de facto have to do manually. Something that no one really likes to do, and that has to be done. So now we have examples, we know what we can do with these automations, and now what platforms can we use for these automations?
I would say that there are three leading platforms for automation.
One of them is Zapier, another one is Make.com, well the third one, for those of you who use Office 365, for example, there you have this tool called Power Automate, and with just these tools you can really connect to many, many services. Each of these tools already has predefined connectors. This means that, for example, you can choose, hey! I want to connect the Google Workspace Gmail service specifically to my AWS, for example, and to my Jira and some other tool, for example, to some CRM called Hub Spot. That is, for example, if a query came in via email from my client, I want to automatically create that record in Hub Spot. Yes, I want to have a record created with that customer right away, and I want, for example, to send something else there in response to that customer. This is another example of automation. Well, how do these platforms work? That's where we choose for ourselves what tools we want to connect.
We have all sorts of things listed there that we can do for ourselves, so it's always worth reviewing that, to see if the automation we want to build is possible to build with that tool.
And here a small spoiler these platforms allow us to do certain things that other platforms allow us to do. On the other hand, they never cover, or rather, very rarely cover 100% of the capabilities of a given platform. This is based on the fact that simply the APIs, these End Points of these applications, are dressed up in such a user-friendly way. That is very simple blocks in these platforms. If it wants to connect to my Gmail When an email is coming to this Inbox. That is, if an email has fallen into this inbox, there we can configure how we will recognize that this particular email is to be automated, e.g. by subject or recipient, etc. Such as rules like in Office. You know them for sure. That's when something is supposed to happen, and we connect it to the next tool. On the other hand, as I said, not all possibilities are always available from these platforms. And then we sometimes have to use some custom solutions, and learn to use just Rest API.
Mostly, because mostly these platforms work on the so-called Rest API. I won't go into details now about what exactly this is, but I will tell you briefly that these are simply interfaces, stubs of these applications, through which we can connect via programming and trigger certain actions in them.
So in summary, we have three leading tools: Zapier, Make, and Power Platform. And each of them works in the same, very similar way. We will build ourselves such a dependency tree where if this, then that. This is exactly how it works. If this has worked, then this is supposed to work, and then this. And if this condition is met or not, then this is supposed to happen if this condition is met and this is supposed to happen if this condition is not met. That's how these platforms function, this is how they function from the cost perspective. First of all, if you want to integrate platforms with each other that are paid, you have to have accounts on these platforms. You have to pay subscriptions in those accounts, in those apps, in those platforms. Well, you still have to pay for the subscription to that platform. Mostly these platforms work in such a way that we have different tiers, and different levels of subscriptions, which we pay depending on how much automation in a month we do, either automation as a whole workflow, or steps that go through there.
Each platform bills in a slightly different way and has a slightly different price list, so here I'm not going to talk about the price list either, because these price lists are variable, so it doesn't make sense for me to talk about exact prices.
They also often have very trial plans or free plans. Where of course we have a limited number of automations we can do. But it will give you some idea of how we can use these platforms in general, what they look like, and whether this is the solution for you. So this is a first easiest approach to no code, which allows us to automate our work, and save a lot of time. Saving time equals saving money. So that's a good place to start recognizing this topic in general. Right. Another element, another category that we can solve with no code or low code applications is, of course, web development. What is web development? Web development? Of course, as the name suggests, it allows us to build websites or web pages. Just what do websites really mean? Now, websites are of course something like business cards and landing pages, web applications, and so on. Here we also have a very wide range of what we can build. Because of course, we can build our company's website, which will simply be a business card, but we can also build some kind of social media platform, or a CRM, or ERP, which will actually be a web application.
And for all this, of course, we have tools. So if I were to give exact examples, with these tools we can build just social ERP platforms, CRM, e-commerce, marketplace, and all kinds of web applications that come to mind. And does this mean that these applications will only be available on the web, only on devices such as laptops, computers, etc.? No, absolutely not. It means, of course, that we can build RWD on most of these platforms, that is, Responsive Web Design. We can do, that is, these platforms, and these websites will be one hundred percent responsive. That is, they will be adapted to all devices. Of course, as long as we take care of any devices with web browser support. If we take care, of course, that there is this view adapted to the mobile view, then our web pages will also be adapted to this mobile view. So if we already know what we can build, what are the examples, and going back to those examples for a moment.
It is, of course, we can build ourselves these solutions very simply, very quickly, in a completely uncomplicated way, in order to validate something. Or to quickly put some kind of business card of our site, of our services on the Internet. We can also build very complex web applications, which will really be huge, which will have hundreds of thousands of users, which will scale, have integration with third-party platforms or services, and so on and so forth.
Here, in fact, the limit of possibilities is heavily unlimited. It will really only depend on what expertise we have, what experience we have in building these platforms, and what de facto platform we choose to build our solution. And this is where, in this clever, way, I would like to move on to what platforms, in general, we have for web development in no code available, which we would anyway recommend to you. Such the most popular platforms, which we also use, is Bubble.io is of course also Webflow. There is a slight difference between these two tools. In both, of course, we can build ordinary websites, and web applications, while these tools were not created specifically to do the same things. That is, there are minor differences between them, And I will start with what Bubble is best suited for. Bubble is one of the most popular no-code platforms, which now has more than 2 million users, and is already 11 years old, so it's a very mature platform, constantly developed, and so on.
Bubble, on the other hand, was created mainly for creating applications without using code. Of course, we can use code there.
I have already talked about it on one of my previous podcasts, so I invite you to listen to it. There you will learn more about how exactly Bubble works, what it allows, etc. On the other hand, it is a very comprehensive platform, which is mainly designed for building web applications. It provides us with adequate scalability, provides us with the right tools to build very complex platforms. On the other hand, if we simply want to put up a page, a business card of our company, a quick landing page, or anything else, Webflow is definitely a better tool for this. And why? Because Webflow is, one might say, such a WordPress 2.0. It is a platform that is built to work lighting fast, that is, it uses natively already such services as Fastly, it is a service that provides us with all content delivery. That is, the pages that we create in Webflow immediately say in a nutshell, in a nutshell, spread all over the world. So that from anywhere in the world they load a hell of a lot faster, as fast as it's even possible, they are beautiful and they are responsive.
In Bubble, of course, we can also build responsiveness, but the advantage of Webflow is that it is dedicated to that. We have the whole CMS, or Content Management System, built there right away, where we can very easily add blog posts configured, of course, for our requirements, or some case study or whatever. All the things that are supposed to be on our site dynamic. And now. Generally, in Webflow we can also build applications. However, Webflow at this moment does not yet offer a no-code approach to building applications. There we can add our custom code to this solution, which is of course based on HTML, CSS, and JavaScript. By adding our own code we will be able to extend the functionalities of Webflow with just the functionalities of an application. For the moment, Webflow will allow us to build a simple store, because this is an additional module that we can add there, as well as allow us to log in or register users. On the other hand, if we want to add some other, more complicated functionality there, we will already have to use custom code.
So, as you can see, there are minor differences that may not be so clear to you at first glance when it comes to these two solutions. But I assure you that if you come up with a specific request, what you want to build, you will quickly discover the differences between these tools and see that Webflow is definitely better for building.
Such lighting fast super extra beautiful websites that will work mega fast, mega cool, and really pretty, will give a great feeling to users. Bubble, on the other hand, also allows for this, but it works in a completely different way. A lot more commitment is needed from us there, well, and it's more geared toward building web applications than for building pages. Webflow building pages will undoubtedly just be better. Both of these platforms. If we also want to talk a little bit about what billing is like with these platforms, both of them work on the basis that there we pay for hosting, we don't pay there for access to the editor. We can build apps or sites for ourselves for free, and as long as we don't want to host them, we don't have to pay for those apps. You just have to reckon with the fact that on the free plans their functionalities are unfortunately limited too, so you won't be able to use all the editor's functionalities until you pay for a plan. On the other hand, these plans start from very low amounts in the case of Bubble it is currently $29, in the case of Webflow perhaps $18.
However, as in the previous case, I refer here to the price lists of these applications, because they can simply change dynamically and what I say will simply no longer be valid.
So this is what web development looks like using No-code. Of course, we have some other no code platforms that are used for completing strictly no code tasks. Because in the case of Bubble, we can develop it with custom code, because there are platforms like Softer, which also allow us to build very simple applications. There are solutions like Air Table, which allow us to build such simple applications based on spreadsheets and so on and so forth. Maybe more than a spreadsheet it's about a database, which is similar to a spreadsheet, while these are already more such limited solutions, serving a little bit for something else. Okay, we've already talked about automation, we've talked about web development, so now I'd like to tell you a few words about Mobile Development. Mobile Development, as the name suggests, allows us to build mobile applications, native mobile applications. What does native mobile apps mean? You must be aware that in stores such as Google Play or the App Store, we can put applications that are written in a way that is dedicated to that platform, that is, in a language that that platform accepts.
This will be a native application that we download from the store, install on the device, so it will run lightning fast.
It's just going to be the main part of this application served from our device, and the content fetched from the server. So these are the kind of applications that are a bit Frontend that has to talk mostly to some Backend. Of course, we can still program something to make it work too, but rather most of these applications are based on the fact that somewhere in the backend there is some Backend running. Of course, I could multiply examples of such applications like up my sleeve. It will be Uber, it will be Facebook, it will be Instagram, it will be WhatsApp, it will be Gmail for phones, and it will be LinkedIn for phones. There will be all kinds of apps for that, which you download yourself from the store in Google Play or the AppStore. Some we install on our devices now with the help of no code we can also create such applications, and note they will not really be any different from the applications you know you use on a daily basis. Why? Because there are already platforms, which we are about to talk about, that allows us with no code or with low code to build precisely in these native languages and connect to different Backends.
Such as Google FireBase, as Xano, such as Back Endless, or our own back end, which we will put up on our own somewhere in our company. What does that mean? It means that at this point we really have unlimited possibilities to build mobile application solutions, mobile applications, and native applications. And now yes, of course, we still have a second type of application, the so-called PWA or Progressive Web Apps, which we can also put in the store on Google Play. In the App Store, we can't. But for this we also have a solution. We can put such a mobile view of our app in a special wrapper. This is such a native app, in which we place a Web View, that is, a view of the web page, which launches just our app. For the user, of course, this is invisible. Such apps won't work like a native app, of course, because it's still a web page ang will load just like a web page. It works just like a web page, but for simple MVPs, for the first products it can be as good a solution as possible, because it simply saves time or money.
In building our first such mobile app and this is the kind of solution we can build with Webflow or Bubble.
Native applications for this we can build on platforms such as Flutterflow, DraftBid or Adalo. And now I want to briefly stop at these platforms. Flutterflow is a platform that, as the name suggests, is based on a framework, the Flutter language is based on Dart, and Dart is based on C-type languages. Generally speaking, with Flutterflow we can build native applications based on Flutter. It's a platform that allows us to build really beautiful, really responsive, really fast mobile apps, native to both Android and iOS platforms. It also allows us to build. Interestingly, it's still in Beta, but it also allows us to build web apps, while its main purpose is to build native mobile apps. Its main advantage is that it has direct integration with Google Firebase. We can extend it with our own APIs, which means it also integrates with third-party solutions. It has built-in integrations with Revenue Cutt strip, BrainTree, Google Analytics and several other solutions, and we can also add our own code to it, at which point we can add our own code, because really our possibilities are unlimited.
In addition, this platform also allows us to export code, which means that we can be very much part of the application. If we know Flutter, we can build it ourselves using the drag-and-drop interface. Then export this code and add to it already in our own editor in some IDE, add our own functionality or our own code, and put it in the store. On the other hand, this platform also allows us to directly place these applications built on it directly in stores like Google Play or AppStore. Great platform, highly recommended. We operate in it ourselves. Here, however, when it comes to access to this platform, we pay for access to the editor. We don't pay for hosting apps, because de facto native, mobile apps are not hosted in any way. We host possibly the backend of these applications somewhere, and it is the backend that we will have to pay for. But this is a separate topic. Here we pay for access to the editor As long as we want to use it, we have to pay for this editor.
Another platform worth looking at is DraftBIT. It is a competitor to Flutterflow, while it is a competitor also because it does not use the Flutter Framework, but is based on React Native.
That is, the entire solution generates React Native code. We can also add our own code based on React Native there. The platform, on the other hand, has much less integration and no native integrations at this point. We can add code snippets there that allow us to integrate with third-party platforms such as Strike or whatever else comes to mind. And here, too, we pay for access to the editor. We do not pay to host this application. And last but not least, the platform, which is used to build simpler applications, doesn't give us as much freedom when it comes to building applications, because we can't add our own code there. It is also not as extensive as the previous two platforms. This is the Adalo platform. If you have an idea in your head for a simple mobile application that you just want to deploy somewhere, test it, you want to build it quickly. Then Adalo is certainly a great solution that will allow you to build such a platform quickly, in a complementary way and quite efficiently.
Okay, we have already discussed mobile dev. What can we de facto cover with it? What examples do we have of applications built with these solutions, and what are the most popular platforms?
Now let's talk about the Backend. This is something that can utilize our web platforms as well as our mobile platforms. The Backend is obviously something essential when it comes to building an application, because the Backend is our database, it's our functions that happen on the server, and so on and so forth. All that is responsible for the de facto operation of our application, to a large extent, for hosting our application. Although hosting may not be the right word in this case, here with the Backend no code we don't get the application code. These solutions are not meant for hosting and what de facto we can build with this backend, no code or low code. We can build the heart of our application, which is just to create all the functions, create databases, expose the appropriate endpoints, manipulate our data, build calculations, plan backgrounds, shuffle, and so on and so forth. They simply allow us to build the entire Backend of our application. This Backend, of course, we can connect to these platforms like Bubble, Webflow, Flutterflow, Draftbit, and so on.
Because we have to do it with these applications.
Because mobile apps obviously don't give us a backend. A platform like Web doesn't give us a backend. A platform like Bubble gives us its backend, but we can use another one if we want it to be more flexible, more mobile, and more adaptable to integrate with other solutions as well. This is where we can build ourselves solutions. In terms of examples, again I would have to go with all the applications that you use on a daily basis, like Uber, Facebook, and whatever else. That is all apps that have a database, of course. That is, 3/4 of the applications have some kind of database, have some kind of backend, have some kind of server where we build user access dependency functions, and so on. And now, so what kind of platforms do we have? When it comes to the Backend, I'm going to talk about one of the most popular platforms when it comes to building the backend, which is a no code platform per se. Maybe it is in some part a no-code platform.
You could bend reality a bit to call it that, and it is namely Firebase from Google. Firebase is the kind of platform that a simple quick way allows us to run a backend, allows us to run a database that we will be able to connect to our applications.
Well, and it's platforms like Bubble.io or Flutterflow that have direct integrations with those, so we will be able to connect ourselves to that very database that will be there. Obviously, this is a great solution. It is a solution that is used by the largest of this world, that is also used by smaller ones, that is used by very many companies. On the other hand, if we want to build some backend functions there. Well, we already need to know some programming language, with the help of which we will program ourselves. There with the help of a backend, where we will be able to just implement push, notifications, sending, sending emails, and so on and so forth. Now, I'm not going to get into a conversation about exactly what the backend is. We'll talk about that in one of our next episodes. Where we will go through exactly what the Backend is, how we can build it, what platforms we have, their advantages, disadvantages, and so on. Today I want to tell you briefly, that Firebase is of course such a bit of a reference when it comes to these Backend platforms.
Well, and we have two most popular No-code solutions, or rather low-code ones too, for building these back ends Xano and Backendless
The two solutions are a little different. I mean they very much rely on the same thing. That is, we build ourselves an endpoint, we build ourselves some functions, we build ourselves a database, where drag and drop we say what should happen in turn. That is, if a query has been sent to this endpoint then do a query in the database, that is, search our database, filter the change records this way, not that way, and spit out some information back to this user. Yes, that's what Backend is generally about. Well, and Xano is such a very friendly, very cool, very scalable, very flexible solution that allows us to integrate with very many third-party solutions. We have unlimited third-party integration there, because we can add our own code there, which is JavaScript-based. It's a great solution with which we'll be able to build a very scalable Backend in a fast, great, clear way for everyone, which will work in an almost lightning-fast way. We will not feel the difference between this Backend and such a traditional one.
On the other hand, we have Backendless, which is a more advanced solution for more hardcore developers, although Xano obviously doesn't stand out from anything, but Backendless allows us to do a lot more and add different snipets
From different programming languages. Much more there we can get into the guts of this backend of ours, what's going on in it, the manipulation of this data and so on and so forth. On the other hand, here more advanced programming skills will also be required of us. We will already have to know a language, understand semantics, etc. etc. If I were to compare these two platforms Xano and Backendless, which one is better I don't have a clear answer. I would only say that if we have Google FireBase as a reference, well Backendless list will be closer to just this kind of native approach. This kind of programming approach, Xano still allows us to be very flexible, add our own code, manipulate any data and so on. But it is much more user friendly. It's much more flexible in terms of being able to build it quickly, without super extra heavily specialized knowledge, to crank it out. We can still go very deep in there and we will have to have that knowledge as well.
Whereas it's so much more I would say flexible it's so much more flexible than Backendless itself, Backendless is more just such a Swiss Army Knife for creating that backend and those platforms of course we're already paying for the hosting.
Both of these platforms are hosted in the cloud. Both of these platforms give us super performance, based of course on cloud solutions. We have cash available there. We have various solutions available there so that we can speed up the performance of this backend of ours even more, so that our users don't feel a total difference if we're talking about the standard approach and the no code approach. However, as I said about these solutions and what we can build with it, how exactly it works, we will talk to each other in one of the next episodes of our JUST NO-CODE podcast. So okay I think we've covered all these major categories of no-code, low-code platforms, which is just automation, web development, mobile development, backend development. Well, but of course I would be lying if I said that there is not another such category, such a bag, where we already have such very highly specialized tooles, very user-friendly tooles, with which we will be able to build very specific solutions, very limited solutions, but on the other hand covering our needs as well.
If we want to build something just very specific, very small, covering our needs.
What, for example, membership building platforms, chatboot or landing page, or just some tools based like Air Table to build mini applications based on our automation database based on what's happening with our data, we have just such different platforms. For example, if we want to build some kind of Membership platform, where we just build some kind of user forum, some kind of community, and around, let's say, our community, and around what we create as artists, as some kind of specialists, freelancers, as gurus in some category, well we have, for example, solutions like Discord. These are tools that allow us to build such a membership platform at the same time. To automate ourselves some things there adding some things without knowing the code. Of course, this platform is based on the fact that we also have to pay for the subscription there, but thanks to this we will be able to build ourselves such a membership platform in a fast, clear way and we will not have to play with building a login page, forum, etc.
, which we would have to do from scratch. From scratch, which we would have to do with other platforms. If we would like to build ourselves some, let's say, collect information from our users, do some surveys among them, well, we have solutions like Google Forms, we have solutions like Tally, as we have solutions like Type Form, where we can build beautiful forms, with the help of which we will be able to collect various information from users, surveys, examine their satisfaction, and so on, and so forth.
This is also some kind of no code tool. We don't have to build such forms using custom code or other no code platforms. We have a specialized tool for building just this type of solution. If we want to build a chatbot, i.e. implement a chatbot on our site, which will answer our users' questions, and so on and so forth, it will be an intelligent robot, or it will simply be a robot that is supposed to follow some designated path, we have, for example, such solutions as Land Bot, with the help of which we will be able to build ourselves this whole path. So here, as you can see, these solutions are very, very many, and maybe in the future we will make an episode, where we will just touch on the topic of such various interesting no code tools, very much specialized in their plot, which will allow you to build very specific functionality. So, as you can see, we processed today. To sum up, we have covered a piece of the platform today, a piece of knowledge about what de facto with no code we can build, what category of solutions we can build.
We've gone through examples of what falls into these categories, what de facto we can do, what platforms we have out there, how they function, what they allow, and what the billing is with them.
I hope you found today's episode helpful. It proved interesting, and will prove helpful. I very much hope that through it you will be able to somehow make your work or your employees' work easier, more systematic, more automated, or you will simply be able to validate your solutions or your ideas faster. That's it from me for today. Thank you very much for your attention and we'll hear from you in future episodes. Hi!
.svg){kind=small}
21 05' 49'' E
21 05' 49'' E
