[00:00:00] Hello, and welcome to another episode of the process and automation podcast was the automation guys. So today, um, we thought we will go back on the low code application development. And when we speak to, um, our, our customers and our prospects, um, yeah, w we, we also hear a lot of. Uh, problems from problems they have may be, um, was previous projects.

[00:00:36] And, um, and today we thought we will cover some of the pitfalls, um, uh, of low code application development. So you don’t have to do the same mistakes again. And, um, yeah, I think that that’s, that’s what we want to cover today. Um, should we cover what is low code and why local development, uh, in, in general matters.

[00:00:59] Yeah. Sure. [00:01:00] So of course, for some of our listeners. Haven’t heard about low code, low code is a discipline of software development whereby you use no coding or minimum coding to create integrate enterprise grade applications. And, um, what that means is that you can create software up to 10% faster by using a low-code platform and the configuration of the.

[00:01:31] That allows you to, um, assemble business applications. Um, so, you know, low-code development is, is becoming very mainstream. Um, a lot of businesses are utilizing it and, um, you know, if you do it right. Low code allows you to deliver, um, better functionality, um, than, uh, you know, compared to conventional development at a, at a, at a faster [00:02:00] pace.

[00:02:00] And also, um, you can rely on, um, on small, smaller teams, smaller development teams, um, to deliver these software. And of course, when you. Um, collaborate with end-users Loco lends itself to, to that sort of end-user collaboration, software development. It’s a very powerful, um, methodology to, to create, um, applications.

[00:02:25] And, uh, you know, what we’re seeing out there Sasha is that, you know, many it teams out there that is starting to use local. Is only really starting to scratch the surface of the potential of it. And, uh, you know, we see a lot of pitfalls in, in, in some low-code project where, um, these low-code projects are.

[00:02:50] Uh, run with high code approaches. So, so what we want to cover today is really to, to touch on how, you know, how, how do you get the full power of, [00:03:00] of, of, of low code, um, and Loco development from your existing it team, and you know, how do you, how do you shape that team to, to, to bring it out of that sort of conventional Java and C plus plus, and C shop development and bring, bring those, those, those.

[00:03:21] That those methodologies and those, those ways of development, which, which can be a bit bloated at, at, at some, some stages or some instances, and, um, kind of address some of the common pitfalls, I guess, to, um, to really, uh, you know, sort of exploit low code better in your organization and, um, you know, to, to roll out prod projects, using low code, um, you know, With, without, you know, those pitfalls and encountering those pitfalls today, it will be sort of four pitfalls.

[00:03:57] And, um, if you, if you, [00:04:00] um, take those, um, things on board, I’m sure, you know, your projects will be, um, uh, far more success. Um, as, um, than, than before. So let’s, let’s jump straight into a pitfall number one. Um, um, what we see as well, and you mentioned, you touched on this earlier, so the development teams are maybe too, too specialized in high code and, um, very often too big.

[00:04:25] And, um, so that, that really. This is what we see was the traditional development teams, um, full of excessive, uh, intern interdependencies, and, um, effectively, um, it was low code. You will generally go for, um, Uh, for, for an approach where, um, where you have a small team, uh, was all the skills you need to really go from idea to application.

[00:04:53] So, so that, that kind of, uh, idea and, um, uh, and then, um, and these [00:05:00] small teams, they stayed together sort of across the projects, sort of don’t have to spend time learning how to collaborate in general and, uh, And these, these small teams, they have a really good set of functionality or skillset, um, something, what we generally need more in the market to, um, um, to, to do more of these local projects.

[00:05:24] So you have, uh, generally people who are the product owners. Um, so that’s, that’s the role that does not really develop the features, but, uh, Um, so, so it comes, comes into the, the project or into the team from, uh, from a business perspective, you have roles who are very skilled UX, design skills, um, people who can really be.

[00:05:49] At that really user experience and really good user interfaces, interaction, design, all that kind of stuff. Um, technical design and architecture skills, um, uh, [00:06:00] business analysts, really gathering and digging deep into the business requirements and off the user needs. And of course you need this testing and, um, and someone who was leading, uh, that, that small team, uh, and typically.

[00:06:15] Maybe that will be a scrum master. If you’re familiar, was that agile methodology scrum, a scrum master would also be part of the role and was this small, powerful unit. You can really get everything done. You don’t have to go to another team and ask for help. You can really has not that unit. You can, um, you know, really from idea to deployment, go live, you can get.

[00:06:41] Yeah, exactly. And that’s, that’s, that’s a good point. I think, you know, w w what you’re talking about is this sort of, um, people that’s interchangeable with inside the roles. So, you know, you touch on the fact that you have. Product owner. And that’s the [00:07:00] person that obviously need to transform something on behalf of the business.

[00:07:05] And again, what we see in, in, in a sort of a streamlined optimized, low code team is that the product owner won’t necessarily get involved in if the technical elements of the. At all, it’s good for project or product owners to understand the capabilities of what low code can offer. So they can articulate that to the Bennet, the business, including the benefits of it, how quick it is to roll an application out.

[00:07:30] But of course, like you’ve touched on those other disciplines, a good UX designer. Um, a technical designer, a person that’s in charge of architecture and business analysts that, that looks after the requirements and tease that out from, um, you know, sort of the end users and a test function, and then obviously a team leader or a scrum master.

[00:07:52] So what we saying is that, um, you know, We want to design our local team. So, [00:08:00] um, they embrace collaboration and they, they should also be multi discipline. So a good UX designer should also be somebody that can develop some, uh, low-code elements of a system, for example, or somebody that does testing should also be able to, um, be able to collaborate with their end user on the requirements point.

[00:08:23] Okay. You know, if you create this, this sort of interchangeable roles within sight, the team, you, you kind of minimize dependency, specialized dependencies between people and you create a truly sort of agile and nimble makeup of the team so that, so that people can do some of the different disciplines, um, you know, include.

[00:08:47] And user engagement, um, you know, being able to talk to the end-user and like you mentioned, um, If you compare this to traditional Hy-Ko development, where there’s a dependency on, uh, [00:09:00] a database person to go and create a database while you don’t have it in this instance, because obviously, um, everybody in that team knows how to configure a, a low code data storage, um, area and the system.

[00:09:16] So, so it just speeds that, that, that part of the process. Yeah. And, and, and, um, some, some companies, or some people might say, okay, all these skills while, uh, do I need to, uh, need a person. Uh, each fall, these skills, uh, then suddenly I have a team again, of like six, seven people. It is already quite large in my thinking.

[00:09:41] Um, so this is what we hear. Sometimes you can kick off. Um, sometimes people can. Different hats, the skills need to be available. It doesn’t need to be that they necessarily could, could sit with the same person. So that’s, that’s very important as well. So you don’t need to have a [00:10:00] team of seven people to start off with.

[00:10:01] Um, as long as these skills are available, you can get going. Yeah, absolutely. You know, a product owner in a, in a, in a very small low-code project, it could be a version. One of a project could actually be the, um, the lead end user stakeholder. You know, that person could functionally be. Responsible for what needs to be achieved to drive efficiency or to create automation, but you could have one person fulfilling the UX design, the technical design, then the business analysis, talking about requirements to testing, and then obviously the rollout of the application.

[00:10:45] And scrum master duties, like having, uh, a standup with the product owner every morning to say or periodically to say with, with, well, I’ve implemented this [00:11:00] feature now, can you have a look at it? Can you provide feedback? Um, of course, if the project is larger than you would have multiple people, um, fulfilling these, this, this particular roles.

[00:11:11] But I think that the key here is that. It’s, um, it’s truly, cross-functional what we expect from, um, low-code developers or members of the low code development team. And, you know, they can act in all of those, those different. Disciplines. Um, so it’s sort of a generalized specialist, um, uh, if you want to call it that.

[00:11:39] And, um, and again, you know, they are, cross-functional, they’ve got good skills to collaborate. Um, you know, they can, um, Uh, understand requirements, translations, translation into, um, a solution idea, for example, um, they can articulate that. [00:12:00] So again, I think, um, if the team is too big and too specialized, that that’s generally what we would consider to be a pitfall.

[00:12:10] We, we would like to avoid. So normally, so let’s, let’s jump into the second pitfall. Um, so, um, you’re not digging deep enough into the problem. So when you think about. A traditional software development, um, really relies on non business analysts who, um, sort of the connection, the translator between the business users and the technology teams.

[00:12:36] And, um, yeah, so usually these, these two sides are very siloed from each other. Um, so we talked about these skills. If, if it’s not necessarily siloed, then it works much better. So, um, um, yeah, so, so usually when they are siloed, um, Um, they experienced problems, um, um, of, of being separated and, um, [00:13:00] and developers attempting to really, uh, go really crazy into the problems.

[00:13:06] Um, and I’m not really good with communication and. Yeah. So instead of, uh, programmers with a decade of job experience, look for, for developers who are more, more really interested in solving problems than writing code. And this is what low-code is all about. So it’s not about writing lots of code. Um, so they may have one of them.

[00:13:27] To technical specialties as, uh, as well as the, sort of the general knowledge of software development and, um, and the business domain. Um, so that’s, that’s a really, really good combination. And, um, you know, as you find the right people, you should, um, also foster a culture of, uh, of asking open-ended questions and.

[00:13:50] Otherwise people say yes, no, that’s, that’s really, really not really getting you anywhere. So, um, you never take a requirement, [00:14:00] uh, sort of at face. Oh, you so you always should ask why. Um, so in some, some cases you should take, not just one level of why she should maybe half or you should dig deeper and have maybe three or four times of why.

[00:14:14] Um, very similar, like what, what the kids are asking. Isn’t that one that growing up, they asking why, and then you have to explain it and why and so on. And so, but then you really dig deep and you get the full understanding and. Yeah. So, so all this I’m interviewing was why and asking, uh, open-ended questions will, you know, will happen usually at this project.

[00:14:36] Initiation of course. Um, and, um, yeah, it was those collaborative sessions. Was it was everyone in included? Uh, yeah, you will really find, find out what’s what’s the goal, uh, of, of the, of the application and, um, yeah, so that’s. And it’s super important to, to dig deep. Um, otherwise you will, at some point [00:15:00] go alive.

[00:15:02] It’s just missing all the expectations someone had for the, for the project to sort of summarize this. You should really have these five, five areas. So what do you want to achieve was the application, um, which end users and stakeholders will benefit and what is the problem or the need, the application must address.

[00:15:25] Um, so what are the current pain points, bottlenecks and all the other desired benefits of that application and, um, w what’s must have features and functions should the application have. Um, and then you come up with your, why questions? Why, why are these features and functions, uh, sort of must have, and, uh, Yeah.

[00:15:48] And at some point, um, you know, you’re quite, quite, quite close on what is really needed and what are the measurable business goals, um, uh, for, for that, um, uh, in, in order of priority, [00:16:00] et cetera. So, yeah, so these, these are really, really important, um, uh, areas to look at. Um, and if you do not want to, uh, Uh, disappointment at the end, please avoid that pitfall.

[00:16:18] Yeah, exactly. So the third, but for that I want to touch on is just a to do with feedback. Um, general feedback, when you. Develop an application. And, um, you know, I would say that generally, you know, people will say, uh, feedback is very slow. It’s very scarce and it can sometimes be distorted and, um, you know, with low code, we can remove some of those obstacles that.

[00:16:50] Projects down. Um, you know, when, when you look at Hy-Ko projects, for example, and, um, you know, with these traditional development practices that the [00:17:00] feedback loops are, are really a, sort of a, almost like a ferry between. To places where business users on the one side and developers building applications is on the other side.

[00:17:13] And, you know, you, you, you constantly have to Fareed information, information back and forth very slowly, probably sometimes by email, uh, or, or long meetings. Um, so it’s a very high latency process and, um, you know, there is a risk. That, that there’s distortion, you know, when, when information gets or any feedback is varied between the, the sort of the two parties, you know, the business side and application developers.

[00:17:44] So, you know, a solution for this, um, to avoid this, but for emerges when you. Bring the business users and developers very close together to create these applications. And like you said, Sasha collaboratively where this, [00:18:00] this, this open discussions on the next feature that’s been worked on how it works. Um, perhaps it could involve, uh, a sort of a visual wireframe, how that particular feature will be, uh, configured in low code.

[00:18:12] And it could be discussion around that. Um, so low code really bridges that gap. That, um, that, that, that we require to, to sort of theory that the, the feedback between business users and, um, on the one side and application developers on the other side, because of course, what we can do with low code is quickly create something, showcase it and say, is this what you mean by a.

[00:18:37] Uh, a reconciliation screen, for example, and the business users can say, yeah, we like that, but can it also have this, this and this? So it’s very easy to, to communicate that, um, and build that bridge, almost that functional bridge so that the requirements and solution, um, you know, can flow freely. And again, it makes collaboration very, um, [00:19:00] very easy and it encourages very clear and frequent input from.

[00:19:05] You know, all of the stakeholders involved, um, you know, which, which also by the way, help you to test some certain assumptions perhaps that, that the developers has paid and, um, you know, and it, and it goes a long way to, to actually finding the right solution because it is something that you can sort of experiment with.

[00:19:23] Uh, and again, you know, if you, um, have this mindset. Increased collaboration and sort of iterative development. Um, you get very early buy-in from stakeholders, especially end-users because they can see, um, you know, th th th the system or the proposed solution that you can provide in, in, in the system very early.

[00:19:50] Um, so with conventional development, everything happens in the silo and the sort of the value comes out at the end of the project. Um, [00:20:00] so. With low code, we could sort of, um, uh, sort of show the users, the application and they can validate it and sort of influence how it takes shape before they eyes. And like I said earlier, you know, you could use prototypes and in progress built to give the user something concrete to react to, and, um, to validate the design and.

[00:20:28] And also to, um, to, to make sure that the development team has got a, a very clear understanding of what’s needed. And so again, I think the message is instead of having this, um, the slow ferrying of feedback between the business and the development team Loco kind of bridges that gap, um, You know, we see that daily.

[00:20:52] We see that daily where we are very comfortable having a developer, um, you [00:21:00] know, interacting with the end user, discussing the design of a, of a component preloaded. Um, that that would have been unheard of because that developer would have, um, you know, received a sort of functional, brief somewhere. They would have had some, some idea of what’s required.

[00:21:20] Um, they would have no sort of, uh, direct input or direct feedback as, as they construct a feature or build a feature from the end-user. Um, so again, coming back to pitfall, number three, you know, let’s, let’s ensure that that that feedback is, is, is, is, um, quick, um, it’s, it’s frequent and of course it’s not distorted, you know, it’s a single to the point, this is how it’s going to work.

[00:21:51] This is a proof of concept we’ve created or. Oh, are you guys happy with this? You know, get, get the results you need. [00:22:00] Yeah, we, we, we going to an extreme actually next week on, on those kinds of things was the feedback. We get everyone. So with 12 people in one room, so sort of. Um, sort of closed, close before go live.

[00:22:13] Uh, but then we’re really in one room sort of focused going through it, high intensity sort of sort of one week in one room, uh, just pizza goes in all the stakeholders, all the developers, the UX guys, really every one of that team and, and the end users sitting there. We’re doing high-intensity testing feedback, testing, smaller changes, small tweaks.

[00:22:38] So that that’s a, that’s a bit of the extreme side, but, um, uh, that is so helpful, um, because you, you closing the, the last glitches, uh, was in a couple of days together, um, and get sort of, uh, while you’re doing this and this week, um, sort of the, the really, really deep commitment and confirmation from the business, uh, that [00:23:00] this is really.

[00:23:01] Um, sort of the, uh, the, the product we want to go live with. Uh, it doesn’t mean it’s set in stone anyway, because we are agile and the next iteration is coming up anyway, but the, it is really, really helpful. I’m looking forward to this one. Um, but yeah, it’s just pre, pre low-code and pre Edgile. Uh, that was.

[00:23:21] That’s just a 200 page document, the waterfall approach, and you just had to do it. Yeah. I mean, we, we, as recently, as last week had a similar, um, I guess a similar sort of session plan right prior to go live. And it was a day before go live and. We discovered that, um, a particular journey, um, required a piece of information, which, um, the end-user w w w wouldn’t be able to provide.

[00:23:54] Um, so we could almost, as part of that acceptance, Real time, [00:24:00] sort of pivot away and create a solution using a lot of smart people in the room, but to say, well, we can actually circumvent that problem by changing a few things. Um, how the application work. Hmm. It was actually in, in the kind of acceptance meeting where that was briefly discussed everybody.

[00:24:22] We had consensus from everybody that that solution would work and, uh, the Loco developer just went and he sort of just implemented there and then, and, uh, on the fly. Uh, I know that’s an extreme case, but it just shows you the hyper agility that, that it provides you where people have got confidence in the fact that the, the ability to change and pervert is there.

[00:24:49] Um, as long, as long as the solution is clear and people understand what it is, um, It can be done. And, you know, that ensured that those project [00:25:00] deadlines, which was really critical because it has to do with patient care at that that was met. And, you know, we, we could go live that that afternoon. Um, and you know, a lot of the, sort of the.

[00:25:12] Project stakeholders just said that they’ve never experienced something like that before, because that would have been such a big blocker for them. Um, whereas with this it, ed is just another, it’s just another thing that. Low-code offers you, is that ability to fix problems very quickly and sweep them away and, or move them out the way and move forward.

[00:25:39] So very, very good story. Um, you know, similar to what you say with your, your sort of intense sessions as well. Um, and it’s just that. That last mile of a project that you could still have changes to, to make a big, um, you know, impact, [00:26:00] uh, you know, towards the end of the project. And, you know, obviously this is a, is a great enabler for that.

[00:26:07] Yeah, I think, um, um, yeah, that’s, that’s very, very important. It’s this feedback loops. Um, and that’s, that’s also, um, one of the next, um, you know, sort of our next bit for, um, traditionally, um, success was only sort of measured at go live, um, so that the spec was written and then a go live, people looked at it and say, okay, that’s great or not great.

[00:26:30] Um, I’m sure there was user testing and maybe that was all fine because. Test cases were derived from sort of the spec. Um, so functionally, uh, yes, it’s maybe the right product and you go live, but somehow then users don’t get it at the end. Isn’t it? So that’s, this is why it’s very important that after the initial, um, uh, Discussions, um, and going deep on the requirements in the [00:27:00] so-called sprint zero, um, after that you w you should continue focusing on, um, on your end users throughout the whole development life cycle.

[00:27:09] So, so you just mentioned Anna, you mentioned that one shortly before go live, but, uh, in, uh, Well, we will definitely have this, these sessions where we speak was end users throughout the whole development. Maybe it’s an eight week development cycle. Um, so we have every, every two weeks at least, um, uh, sort of a catch-up and a review of what’s going on and invite them into the design process that every, every feature new function and, um, and give, give input and ask questions.

[00:27:39] So. So if, if that is the situation for, for everyone involved, um, it is very enjoyable. They can see the product building, they can feel they’re building a product together with the developers, um, that can immediately. Uh, identify, uh, big problems which come up, um, maybe, maybe a feature and [00:28:00] function initially was, was a really good thought through, um, a function or feature.

[00:28:05] Um, but then as soon as you sort of grab it and start using anything on doesn’t work, so we have to go back to the drawing board. If you have that constant cycle during development. Um, maybe give them sort of the keys to a demo system and they can play around with it. Um, so yeah, so that’s, this is why, where you actually, um, where you will be successful at the end or this, these things will make, make, make the success at the end, by including them, uh, during that development cycle and a crowdsource feedback.

[00:28:39] So throughout the company and, um, yeah, I think that’s, um, And that’s key. So if you don’t do that in white, just for, for development team comes back after eight weeks to go live with something then, um, yeah, there’s always, there’s always something which is not as, as [00:29:00] someone thought in the beginning. Yeah.

[00:29:04] I’m a firm believer of sprint sprint, zero design. Um, you know, that that’s the place where you kind of build a very deep understanding of your end users needs and the pain points. And generally that’s a very good foundation to build a system. Um, but I think that, um, having end-users part of that journey gives them ownership of.

[00:29:28] What you building. And I think the successes that comes out of those local projects, um, is attributed to. The sort of the end users and their inputs. And I think that, you know, it gives them satisfaction and opportunity to shine because they could really look at something that’s been produced and see the features and their suggestions and all of the good ideas that they’ve contributed towards built into the system.

[00:29:58] Um, it’s very [00:30:00] hard to design a system from day one. That’s what. You know, all of, all of these, these great feedbacks and, and, and, and accounts for all of the sort of feedback that that users provide as, as you create, create a system it’s very hard to, to sort of look into the future and, and, and understand what that would look like and what that feedback will be.

[00:30:24] Um, so if you built the system with those people, part of it, and you could, like you say, uh, crowdsource the feedback. You know, uh, the ideas from them, um, bake it into the system, um, that coupled with good initial sprint, zero design, that that’s when you truly get to, um, really, really special outputs, you know, where kind of.

[00:30:52] It provides the opportunity then almost for end-users to shine and take credit. And I think that, that that’s, that’s, that’s worth a [00:31:00] lot. Um, you know, especially if, if people look at it and they, they use it, um, they feel like they were part of that success story. They shaped it. And, um, you know, I guess the end goal is.

[00:31:15] For, for, you know, for the application to, to become, uh, as, as much there’s as the application team and they can kind of celebrate the success together. Um, so, so, so, so, so very, very important, like you said, um, common pitfall, successes only measure that go live, but it, it, it should be from day one. We, we sort of create those, those, um, those early releases involve the users.

[00:31:42] Like you said, give them the keys so they could run internal demos for a broader user group. Um, and give them a sense of ownership. Yeah. And sprint zero. Yeah. It’s absolutely important. Um, um, [00:32:00] um, but it is definitely, is always a moving target. Yeah. After, after the sprint zero has been defined in reality.

[00:32:09] Um, well, I would say that, um, if I look back at projects where users are involved from the start, um, it would be very hard to create a backlog, a project backlog with, with all of the ideas and all of the nice things that they would like. That makes their life easy in the application. Um, so when you look at the, the end point.

[00:32:39] Well, the end result, um, you know, it is, it is sometimes, um, uh, so drastically different to, to how you imagined it to look, you know, when, when you look from it from a starting point. Um, so now, and I think that that that’s important because you know, the majority of, [00:33:00] of, of the backlog. That we see. And when I say backlog, I mean future requests and how people want to shape the low-code application.

[00:33:09] You know, that that happens throughout the life, the life cycle of the project. You know, it’s not something that happens upfront. Everybody sits in a room for five days and we decide, you know, this, this is our ultimate list of features we want to see in the application. So, um, so very powerful. Uh, methodology, very powerful sort of way of doing things.

[00:33:34] And, uh, you know, like I say, it’s still gives you an opportunity at the 11th hour to, to make things better and still apply, um, changes or implement ideas to, to make the end result even better. Right. So I hope, um, uh, these four pitfalls, um, uh, effectively adopting a few, uh, agile best practices, um, uh, [00:34:00] help you to transform, um, um, uh, what you’re doing at the moment and transform how you develop applications going forward.

[00:34:08] So it’s all actually how to, how to get even more out of local, local itself, something we’re really passionate about and talking about a lot here, uh, and the podcast and on clubhouse. Um, uh, but there was, there was, um, uh, best practices and to avoid these pitfalls, you can optimize that even further. And, um, as, as, as a big outcome, um, When you apply these, um, uh, these best practices, you know, you will, you will, streamline development, uh, was, was tied to Nigel teams.

[00:34:43] Um, you will, uh, really define how, um, define the right problem. And really get the deep understanding of your users and make it as easy as possible to collaborate with business users. And it will help you to, to sort of [00:35:00] ensure successful applications that are really adopted and laughter that’s, that’s really the key thing.

[00:35:06] Otherwise, your return of investment is. Yeah, it’s not there. Um, and this is what we usually talk, talk in the beginning of those projects was businesses, um, uh, people and stakeholders, what is the return on investment, um, and to actually make that happen, you need to have these applications, um, going live and being used.

[00:35:27] And, uh, and then, then really extend the use of local was in all organization. Yeah, exactly. And I think, you know, um, it doesn’t matter if you’re just getting started with local and you knew where there or low code, you know, you you’re already on the journey and in your process of scaling it across your organization, um, if you adopt these sort of few best practices, uh, and avoid some of the pitfalls, um, you know, you can truly transform long delivery time scales.[00:36:00]

[00:36:00] And sort of just delivering okay. Applications into very rapid development, um, outcomes that delivers outstanding results. So, you know, so I think w you know, you want to be in that place where the, the results are driven by the input from all of the stakeholders involved. Um, do so. By means of collaborating with the business users.

[00:36:28] Um, you know, Ensure that the, uh, applications feel great, they work and, you know, they solved the problems and continue to build them, you know, continue to evolve it into something better. Um, you know, don’t feel pressured or pressurized to, um, you know, implement something too big. Understand, what would be a meaningful, initial belt, what would be, what would make a difference?

[00:36:57] And then really just build on top of that, [00:37:00] um, you know, get wider feedback, bring more features in, um, You know, once you’ve got that culture within sight of business, um, you know, you set yourself up for some, some really, um, you know, uh, uh, good opportunities to, to, to deploy these applications. That, that makes a big difference to people.

[00:37:23] Yeah. And, um, so it’s it’s applications maybe also in the wider sense is isn’t it. So we will speak as well about, um, uh, not just low code apps. Uh, local could also be low court, uh, robotic process automation, uh, could be low code, uh, chatbots. Absolutely. So everything local these days, um, and, and everything, um, Well, we will, we talk here, uh, um, uh, on those podcasts to intelligent automation, um, everything is really around low-code and, uh, as well, no code, um, most of it really, and, you know, all that’s all, all [00:38:00] the best practices we talked about today, uh, applies there as well, not just for, for local apps.

[00:38:06] So, yeah. And then if, if, if you’re interested to, to hear more about low-code and other areas of intelligent automation, um, you know, listen, listen to our other episodes. We, we have done a couple, um, on, on all these, uh, important pillars already. So, uh, you know, uh, will be great if you can just. Yeah, listen to them as well.

[00:38:31] And they will be very helpful. Um, lots of tips already. And, um, yeah, and I guess, um, if you, if you, if like to, to get started with low-code or like to have more information on low-code, uh, um, everyone is, um, invited to, to get in touch with us. Yeah, absolutely. And thanks to all our loyal listeners, um, everybody that listens to the podcast, thanks for all the [00:39:00] suggestions.

[00:39:00] Uh, we’ve had a tremendous, um, sort of, uh, following in, in August, uh, which, which, which is very encouraging to see. So we, we, uh, appreciate everybody that tunes into the podcast. Um, we are looking forward to, to cover more topics, of course, to keep the suggestions coming in. Um, if there’s anything you wish to discuss with either Sasha or myself, you want to get started with, uh, a low-code project.

[00:39:29] You want to get started with automation project. You don’t know where to, to start, or perhaps you might have a existing project that’s in flight and you want to hear more as to different approaches, um, and use some of our experience to, to shape the project. Um, Please feel free to get in touch with us, either Sasha and myself, by the automation guys.net website link.

[00:39:54] And, um, you know, we’re more than happy to continue the conversation, um, with, with [00:40:00] yourselves and, um, you know, and, and, and, and to help people out there to, to, you know, to, to get to the automation, success goals that, that, that they, uh, that they might have for, for this year. And, and, uh, and beyond as well.

[00:40:16] Yeah. Thank you very much, everyone. Thanks for listening. And let’s automate it.

[00:40:26] Unfortunately, that’s it again, with this episode of the process and automation podcast. If you liked this episode, please give us a five-star rating and don’t forget to subscribe to this podcast. So you don’t miss any upcoming episode. We hope you want you in the next. And until then let’s automate.