No-Code Is the Future

Lindsay: There sure are a lot of change maker, buzzwords floating around aren't there. So on this episode, we're bringing on someone who can throw some actual definitions down for some of these buzzworthy concepts.

We're talking no-code, low code and citizen developers on this episode of practically genius. And there is no one better to break it down for us than Sahil Khosla. So heel is a no-code and low-code evangelist course instructor and creator. He's got a great perspective to share from both the development and the implementation side of no-code tools.

In this episode, you'll learn the difference between no-code and low-code implementation pitfalls to avoid and how teams can adopt new tools seamlessly and successfully. Sahil, it's so great to have you on the podcast today. Welcome. Welcome, welcome. Thank you so much.

Sahil: Thanks for having me.

Lindsay: So first and foremost, I think it is safe to say that you are a no-code enthusiast. So please tell the audience why no-code.

Sahil: I'm a developer by training. I've been writing code for 10-plus years, and I stumbled upon a low code tool, which completely changed my perspective on this ecosystem before that I was skeptic. But when I actually used it and realized the potential that these tools possess, I definitely was convinced and I was on board right after.

Lindsay: So you say the word skeptic. So can you dig into that a little bit? What were you skeptical about what was keeping you at bay from trying them out? Just talk to me about that mindset. Real.

Sahil: As a person who writes code every day for a living and as a developer who has been trained in this space, who has went to college for it, first thought that comes to mind, is that okay, this might be something for some side projects or some hobby projects or someone who's just trying to put something together, but it's not going to be something that could be scaled or something that could be customized enough so that it meets your requirements.

So definitely I had those concerns. I actually had a media experience with a no-code tool at that time. I didn't even know it was a no-code tool many years ago, back when I used to work at Deloitte. But now that I reflect on it, I feel that that was definitely a no-code tool in that time. And the experience was really bad.

And I think maybe that drove me away from even looking at any of these options.

Lindsay: Tell us a little bit about what was that aha moment. When you finally did use a no-code tool that did impress you or change your mindset about what it could be used for

Sahil: someone at my previous workplace introduced me to a tool.

They said prior to me joining, they already purchased a license for it. They said that, Hey, for this upcoming integration, maybe you want to explore this tool. And it was a completely backend integration between two systems, data syncing, back and forth. Typically, you know, you were set up the infrastructure for it.

Write the code. And go about your business in a very traditional way. And when he introduced me to this tool, I said, okay. I mean, I'm always looking to try new things and I didn't really approach it from, this is a no-code blue perspective. I just approached it as a new tool. So let me see what I can do with it before final judgment on whether we're gonna use it or not to do the work.

And turns out like, as I was playing with it, I was able to do most of what we wanted to do in the integration just so quickly. And that just like brought that sense of joy and almost relief that this has endless opportunity and endless possibilities because the way that tool was built and designed, it was designed keeping in mind that.

The users still have many number of use cases that the developer of that tool cannot even think of. So it provides that Lego blocks to then go do whatever you need to achieve. So it had that enough flexibility that I was looking for that I usually look for as developers. You know, we want the full flexibility.

We want to be able to do whatever we want and you can do that with code, but I could achieve all of the goals of that project. And that tool had that light bulb moment that okay, the game has changed.

Lindsay: I think a lot of people have that experience when I go back and think about our rise in no-code economy report, we launched last year, we actually found a lot of people didn't even understand what the concept of no-code was.

But when we asked them about Alyssa, no-code tools, they actually could name some and were using some. So it almost sounds like a lot of people are using no-code, but don't know they're using no-code. So how would you define no.

Sahil: I do a workshop and I talk about this in my workshop as well. Okay. Let's start by defining what is no-code.

And I think in my mind, it's a tool that lets you accomplish something that otherwise you would have to write code for to build something unique for which you would've traditionally written code for. But now you're able to do it in a more visual manner. Because I know that no-code has also become a little bit of a marketing term.

Like a lot of marketing landing pages are slapping just the term, no code on it. So I have to also keep that in mind that not everything is a no-code tool because the tool must allow you to build something new and unique that otherwise you would've had to write quote for, but now you can do visually.

So that's how, in my mind I define no-code

Lindsay: and then kind of the next step up from that, how would you describe a low code tool?

Sahil: I tell people often that these things are not visually exclusive. It's a no-code to code-spectrum. And just because you started on one end of the spectrum, doesn't mean that you can go onto the other side.

So it applies to non-technical people and technical people. You started on the code site. Like I did. You can go on the no quote side, you can leverage those tools that the smartest engineers know to use the right tools for the job. And if no quote tool fits that bill, then why not use it? And same thing applies for non-technical people who start on no-code end of the spectrum.

They can make their way up to the coding end of the spectrum. In fact, it's a great way to start because it lowers a barrier to entry. You get to know the basics, you get to build something, you get to see the output, and that might even excite you to go towards the other end of the spectrum and start with something small, some scripting languages.

So when you start to feel comfortable with no-code is a perfect time to get into a little bit of no-code space and to define it for you, it just means that you went out to achieve something with no-code, but you hit a roadblock. The tool maybe doesn't allow for it, or that customization option is not there.

And most of the no-code tools and have this option. Bring in a code snippet to accomplish what our tool cannot do. And that's where you start to get into the low code space where primary objectives of the project has achieved the no-code tool itself. But for that last 10% or maybe 5% that you couldn't do with a no-code tool, bring in that code snippet.

Bring in a little script that maybe your developer friend wrote, or maybe you wrote yourself and extend the functionality of the tool.

Related: Can Citizen Developers Recession-Proof Your Business?

Lindsay: Another term that gets thrown around a lot, especially this past year when people are talking about no-code and low code is the citizen developer. So can you tell us about what you think citizen developer means?

Sahil: It's a person in an organization who does not have a technical background is close to the business, is looking to build a solution to solve their own business. And typically they would've in the past, gone out to the it or the engineering team to get it done. But now with these tools available, they can develop it themselves.

So essentially your citizen developers are people who are developing a software-based solution using the no-code tools without any technical background expertise. So I think they're called citizen developers because there's anyone, but the engineering team and the organization. People from those teams are able to build their own solutions.

So they're being marked as citizen developers. Although I am also telling these people that if you're developing software, you are a software developer. So hopefully we will walk away from sort of differentiating as the two sides in verge. But for now I think when people say citizen developers and non-technical people of in a company or even individuals who are able to build software solutions using the no-code tools.

Lindsay: So, what are some of the things that you teach in this program and what are some of your favorite, no-code and low code platforms you use?

Sahil: The way 30 days of no-code started was my own public journey in the no-code space. I wanted to share everything that I'm learning with my audience on LinkedIn. And I was definitely in for a surprise and a big journey, but few of them that stand out from my journey in these 30 days was tools like the Zapier.

Integra, definitely the two tools that integrate all the existing other tools, whether these are SAS tools or no-code tools or whatever, they may be individual tools can offer only so much. But when you start to connect them is when you start to see a big picture. And for people who don't have any development experience and they need this kind of interactivity between tools, they are definitely looking at Zapier integration, I think it's called make now.

So that definitely forms a core for.

Lindsay: There's just so many tools coming out every day. We're seeing new, no-code tools, doing new functions and features and processes. And one interesting thing we found is we have actually done some research about digital maturity. And what we found is that. The most digitally mature organizations use no-code.

So in your mind, what do you think these organizations have discovered about no-code that has made them go all in.

Sahil: Probably the ease of use, how fast you can get something done, the empowerment that your citizen developers have. I know, like for example, in an HR team or a marketing team or a sales team, they use a lot of these tools that integrate with something like a Zapier and make.

And for them, it's really powerful when they can automate some of their stuff because some of their workflows are very repetitive. And if you have it's blessing, go use Zapier, all you want, integrate your systems, automate your workflow. I think just the employee happiness score would definitely go up because you're able to automate and focus on things that matter and not be doing repetitive work.

Definitely. That's an area I see where no-code is being. I personally used a tool called tray and that's where my journey started. And it's an enterprise tool. I call it Zapier on steroids. If Zapier can achieve that much, imagine what tray can achieve. And then if you hand that over to someone who's a little bit technical can figure it out quickly, the productivity skyrockets, and then that's what people want at the end of the day.

That's what managers want. That's what stakeholders want.

Lindsay: How do you think no-code affects an organization's overall output? How do you think that impacts an organization?

Sahil: They can only be positive impacts of that kind of added productivity. If you think about it for a second, what have you achieved by automating a workflow?

First of all, you're not gonna miss anything. All the things in your workflow are gonna go and you're not gonna miss. Completely just going through a workflow, just because you miss a notification or missed a message or miss an email. If it's automated, it's gonna be taken care of or whatever the triggers you have in place.

Definitely you achieve that peace of mind. You are able to step back and see what your workflow is because when you're building it, you have to think about, oh, these are all the steps I go through. Are these steps even necessary? Can I do them in a different way? So you kind of get this big picture and you're able to step back and really optimize and then implement it that way.

So you get that added benefit. I know, definitely for myself, if I free up my time by automating something, the joy that brings that happiness index quote unquote goes up because now I have this additional time available to work on more challenging projects. So yeah. All in all, it's pretty good.

Lindsay: I think finding that joy in your Workday is so important, but I also know that even if it's the right tool, if it can do amazing things, if it's not implemented well, you can fail.

So do you have any tips or best practices that people can keep in mind as they're implementing new? No-code tools?

Sahil: So definitely something to keep in mind for automation base projects, sort of one pitfall for that kind of project is, are using those kinds of tools is with code.

You always have version control, you know exactly how it evolved. You can go back in.  or you have testing in place before your code is deployed, but with these tools, we are not there yet. I mean, you can have workarounds, you can still follow the best practices that you maybe have like a draft flow, which you test internally only if it's working well, you implement it for your real use case.

So I think that's where partnership between it engineering and other parts of the organization using these suits could be helpful so that they can act as a guide. They can tell them that, Hey, like maybe the right way to do. This way versus just going that way, or what are the best practices that we fall in our day-to-day?

Because as software engineers, these are sort of ingrained in us. We know exactly how to do testing. We know how to ensure quality. So those best practices could be leveraged and collaboration and partnership there becomes even more important.

Lindsay: I think a lot of the times when no-code is brought up, it's seen as this magical, mystical, amazing all powerful tool, but every tool has a pitfall or has issues you need to be aware of.

So what would you say are some of the pitfalls people could fall into with no-code tools?

Sahil: Because it's no-code, you don't have access to some of the tools and processes that you have with code with no-code. You use some kind of versioning tool. You have some kind of an approval process. You have some kind of a deployment pipeline.

So you're going through these checks and balances as you develop that way you can ensure when something hits production, it's working as expected, or it doesn't go to production with no-code, at least right now, at least in the tools that I've seen, you don't have versioning. You don't have this approval process.

You don't even probably. Collaboration to the level that you can have in code multiple people working on the same code base, and then you merge the changes together. So here it's like only one person is working on it at a time, kind of deal as software engineers. We know how to recreate that kind of workflow.

But if you are not from a technical background, you have not worked in a traditional code-based team where they go through these steps. You won't be aware and that could have some sort of negative consequence. And then as I said, it is kind of a SAS in the sense that your data is going to be with someone else.

And I know like some companies might not be comfortable with that feeling because, you know, based on the business you're in whether it's FinTech or healthcare or something that's highly regulated, what does that mean for your customer data? Like, does the tool offer all the guarantees? Are they compliant?

So those kind of checks have to be done ahead of time. If you are on your own cloud or own data center, you want everything you have full control, but if it's someone else, what does that look like? So some of the things still are evolving and I guess the other one is not having any visibility into the infrastructure is great because you don't have to worry about it, but it's also not great because if something goes down.

What is your sort of SLA agreement with the tool? If it's something developed in-house, you are paging your engineers, you're getting on call. You're kind of debugging it, figuring it out. So you have control, but if you're built on top of a tool, then you're kind of relying on their engineers to figure out, and you don't know how long that's gonna take.

Lindsay: Those are really great points. One other thing you brought up too earlier was talking about partnerships and being able to partner with other departments, other teams, other workers.

So who do you think needs to be involved in either the purchase, the exploration or the implementation of no-code tools?

Sahil: Definitely someone from it. And then your security team, if it's a separate part of the organization, but if you are looking for a tool and you're not sure if it's going to be able to do what you need to do, someone has to maybe try it out.

Or someone has to make the judgment about how customizability is, or are we going to be able to achieve the engines result that we want? It might not hurt to involve someone from the dev team or the design team, even to get their take on, you know, what do you think of this tool? Because this is what we are looking.

So it get. To get their guidance and have them identify what could be the blockers down the road, whether it's going to be the performance of the app, built with the tool or whether it's going to be how flexible it is with design. Like, can I achieve exactly the layout that I'm looking for? If you're not able to answer those questions yourself, especially around performance and stability and whatnot, you could benefit from involving someone from the dev team for.

Lindsay: What are some things you should think about when choosing to use either a no-code tool or a more traditional developer tool or using them together even.

Sahil: If I were to summarize it, I would say if you're a mature organization and you already have resources at your disposal and you know, like this is an external facing project where you can't compromise quality can compromise performance.

You might as well leverage your existing resources. Because at this point you already have a tool set and skills in the team that you could probably get a project done pretty quickly, because you're not starting from scratch. So might as well stay custom. But if you go to the other end of the spectrum where you are just starting.

You don't even have revenue yet. You wanna get something done quickly, maybe it's in your best interest to start with no-code. So you spend the minimum amount of time to get something in front of the customers and start getting that feedback loop. And even if you're an engineer, you are a technical founder, you could still leverage no-code tools because it helps you move even faster.

And you have all the skills already to design it in a way so that if your product is working and you know that you need to scale. You've already designed it in a way that you don't have a hard time moving towards a custom solution, if that need be. But then on the mature side of the organization, if you're working on an internal tool where the user base is limited, you know, just your internal employees, you need something quick, you need a dashboard set up doesn't necessarily make sense to involve the dev team to build something.

So yeah. So for everyone, there's a use case for no-code at this point, given the options that are now available and there's a whole sort of list of no-code tools that are just for enterprise. Like they don't even. Non-enterprise type people because they're like high cost and they come with all the assurances that you might need as a big enterprise.

So there's an option for everyone and it's a good time to start using them because it's pretty clear that that's where we are headed. And you can leverage these tools now versus waiting a few more years because you're only gonna get better.

Lindsay: Can you talk a little bit more about why a dev team would use no-code tools?

Are there efficiencies they can gain by having those in their tech stacks.

Sahil: Especially when you're at the prototype level, right. You're trying to develop a new idea. You don't know yet if it's gonna work or not those times I know the speed to market is everything because there's some kind of development that led you to this idea.

Your product person came to you that, Hey, we wanna test this thing. And the last thing they want to hear is that it's gonna take three months or four months to develop the prototype. So what they do in that case is then they turn to the designers to build them a mockup, which people can click around on some predefined spots on this mockup to get a sense for if users like the approach that could be replaced with an actual working prototype built with no-code tools.

So dev teams can definitely use that. And in my personal experience, what I'm seeing is. A software engineers who embrace low code, low code are going to have the maximum leverage in the future because they have the technical capability. And now all of a sudden they're powered with speed. So the amount of ideas they can just build so quickly and test is a superpower because coding already is considered superpower is the most sought after skill.

And then if you already know that and you can do it even faster, the possibilities are.

Lindsay: If you look at the global workforce, it's some crazy, like 1% of the global workforce really knows how to code. That's crazy. And so it does make a lot of sense to start thinking about there are not enough resources to go around for everyone.

So how can you use these tools to fill in those gaps?

Sahil: You bring up a good point. I read that set actually somewhere as well. And that kind of blew my mind because the way things are headed, I can say almost already every company is in some shape or form or tech company. And whether they outsource their tech work or do it in-house, you need people who can develop software and that's only going to increase.

And it's pretty clear that the number of engineers that are trained every year are not enough to meet that demand. So how do you fill that gap? It's a no-brainer that making software development accessible to more and more people via these local tools is the way to go. No doubt. And to fill that skill gap.

Also, if someone is willing to, as I say, break into tech, they wanna break into tech, the barrier to entry with learning to code. Build something meaningful with it and gain the experience that you need to gain. A developer job is really high. Like you really have to be committed if you're already working full time, then it's really hard to come out of that.

But for others who don't have that option, they should really look at no-code and low-code because the barrier to entry is low. You can slowly ease into software development with this kind of tool, because there are people who are looking for no-code developers. Like there are jobs listed online now that are specifically looking for no-code developers.

And sometimes they even have the name of the tool mentioned. And then as I said, slowly, work your way towards the other end of the spectrum, because then you'll be surrounded by developers. You'll be surrounded by that kind of thing. You build a muscle. So it's great for people who want to get into this.

Maybe they missed the boat earlier in their career, but now they can do that. And it's great for organizations. Having access to developers is not cheap. And even if you're willing to pay, there's not that many to go around.

Lindsay: Well, see for organizations who are not using no-code tools yet, but want to begin what is one initiative with no-code that they should try to tackle?

Sahil: Definitely automation could be a good place to start. If you are already using cloud-based SAS products, you already have licenses for them. It's pretty common that they don't talk to each other. They don't integrate well just by themselves. So you could bring in an automation tool. You know, I mentioned zer is a great place to start, or even like, If you wanna get something serious, you can get tray.

So that could quickly help you realize that you can achieve some of these integrations really fast and make the most out of these tools, or maybe just a workflow could be optimized using these tools. So definitely that could be a great place to start the automation space. And then if you want to go a step further, then you can build on top of that and build some kind of internal.

That otherwise you would've gone out to get a SAS product for, or SAS license for maybe instead of getting the SAS product, get a no-code tool, which is, you know, enterprise grade and allows you to build a tool internally to solve a specific problem and maybe train your citizen developers to do it because what's gonna happen is in a typical software development, the business person will write down the requirements and the development team will develop it.

But in this case, The person who was about to write their requirements can just develop it themself. So they exactly get the, what they want. So, yeah. Start with automation, maybe ease into internal tools or productivity employee help type tools, and then kind of go from there.

Lindsay: Thank you so much for joining us for this great conversation with Sahi.

If you wanna keep the conversation going, join me and my cohost Ryan for next week's episode of practically speaking. Where we'll be diving in with some data-driven insights around how the most optimized organizations implement and use no-code tools. And as always, you can find your next practically genius idea at formstack.com/practically-genius.

‍