They LIED to You! No Code vs. Pro Code (The SHOCKING Truth) 🤫

All right, today we're going to be talking no code, low code, pro code. And we're using new mics, new high quality microphones. Hopefully you guys can hear us even louder and crisper and more enticing than ever before.

Welcome to the no Code Wizardry podcast.

Starring Tony Lewis and my old man, Mr. Daniel.

Hi there, boys and girls. Welcome.

Well, I think it's fair to say that this discussion is actually an important one, because a lot of people get no code and low code confused, and there's a lot of people that are used to doing pro code without acknowledging that no code may actually be a better option for them.

That's right. And I like to think about it as. There's always these purists who say that you should always drive a stick shift car because that's where you feel the actual tension in the motor of the vehicle. You can actually feel the road. It's. It's the purest way of driving.

Such a silly argument.

And then you see all the rest of the world that just drives automatic. Why is that? Because it's just easier. It's better. It's less complicated. Hey, I understand if you're going to be driving a Formula one on, you know, racetrack, you. You might need to have a manual, you know, gear shifts, but most people don't need them anymore. And maybe that's a good metaphor for today's conversation.

And you left out one of the most important things, that driving stick oftentimes lead to more problems.

At least when you drive stick, it does.

No, I mean, come on, you gotta. You gotta take care of you like your.

Yeah, you've got your clutch and your clutch, you know, you've got all sorts.

Of, you know, it's more maintenance.

It's automatic. Transmissions have maintenance as well, but not as much as.

I guess then you could start saying, well, you know, maybe you should move to an electric vehicle then. Right, because that's even more automatic. Because there is no.

And there is less maintenance. You're proving my point.

Yeah, I agree.

All right, I agree. So let's start by defining some of these concepts. Okay, so how would you define pro code?

That is traditional software development. It is.

Actually programming into the. Whatever language you're using, be it python, be it JavaScript, be it whatever it is, Ruby on Rails, whatever it is that you're using to program the functionality of your application, actually building the code.

That is traditional software development. That's what we would call, in this case, pro code.

No code, on the other hand, is essentially trying to get as much of your development done without actually writing a single line of code.

Right. That's what we do using Bubble's visual development engine.

And if we get to the middle ground and we find low code, what do people typically mean with low code?

Well, to me, I think a lot of those AI tools fall into the low code.

Basket because.

You'Re not actually.

Developing, but it is creating actual code that you can later adjust and change. So I think that's kind of the middle ground. With Bubble, you do not there while it is creating JavaScript. That JavaScript you never see, it's never under your, you're never touching it, you can't actually, you know, it's part of the Bubble's infrastructure.

So with, with low code, you can actually meddle with the code. You can actually see the code go in, make changes, which could be good.

Or could be bad.

I was going to say it sounds good to be able to have that option, but it's also the way typically people end up screwing stuff up. Screwing stuff up. Building Frankenstein's that they can't fix when they do screw up stuff.

Exactly. And one of the bad parts of that low code model is that once you've made changes, you often can't go back to the automatic part because now the code base is its own, it's been changed.

So let's talk about the strengths behind some of these concepts. Why don't we start with no code first?

Obviously the biggest strengths there are that it's fast, that it is cheap error. Yes. It's easier to maintain. And for me, I think especially if you're a less tech savvy founder, the biggest advantage is that you can actually understand what you're building. You can go in and with not too much of a learning curve. There is a learning curve. You can read your application, you can look at the workflows, you can understand what's going on, you can make changes if you so desire. But the most important thing is you can understand it so that you actually.

Have your fingers on the pulse of your product. Now if you're a very tech savvy coder, then you have that advantage when you do pro code, you know, when you do, you know, traditional software development because you can go in and understand what's going on, or you conceivably can. But a lot of founders don't have that luxury and that means that they're married to their developers or to their cto.

But I've seen Bubble developers who are, and I'm bringing up bubble because it's what we use, but it applies to other no code platforms. I've seen traditional developers move away from pro coding to no code.

Of course it's faster.

It's because it's faster, it's cheaper, you.

Can get to market quicker, you can pivot easily. It has a lot of advantages.

What about, you know, weaknesses, or maybe not necessarily weaknesses, but where would you say no code platforms fall short?

I would say first of all, if you want to build a heavily intensive, graphically intensive application or system, maybe a video game or something like that, well, you would do it with Bubble. That's not what Bubble does. So that's one area that I think that it's not great at. Also, if you're going to be manipulating huge data sets, so you're going to do like a, a big business intelligence app that has, you know, has to process millions of rows and, and make changes to them frequently. That's also probably not the best choice of tool to use Bubble for that.

You brought up video games. Do you know that Bubble actually rewarded. They did a contest not too long ago where they wanted to see what type of AI powered applications people could build with Bubble and one of them was actually a game.

Oh, there's a lot of games that you could build in Bubble, but probably not shoot them first person, right?

Where you're graphic intensive.

Graphic intensive, where you're building a, you know, a virtual universe and people have to see it. That I don't think that's being done in Bubble and I don't think that that's probably a wise choice of, of tool.

I think we've already covered some of the weaknesses behind pro coding, which is it's typically more expensive. You're going to have to hire more people if you want to build the same kind of MVP compared to no code.

It's going to take a lot longer.

It's going to take a lot longer. You do need to have that technical foundation if you're building or investing in an application, and I can speak from experience, things get messy. If you're the founder or if you're in charge of an application that you haven't built or that you can't understand how it was built. Because when the time comes and something breaks or something fishy starts happening, you're dependent on people.

And that is what people call tech debt.

When you acquire traditional software that you haven't built or your developer moves on and you have to bring in somebody new.

That is tech debt, it's going to be hard, inevitably for regardless of how well it's documented, and often it's not well documented, you're going to find tech debt with levels of tools that don't work together, plugins that aren't compatible, software, you know, different layers of the software stack that create conflicts and you weren't even aware of and they're causing problems that you don't know and you don't understand how to fix. That is the reality of a lot of software development.

It is so expensive to pay off that tech debt. It can take years. I'm not even kidding.

Yeah, that's true.

And that is years of you having to pay for devs. And devs are expensive if you want smart ones at least.

Definitely.

I mean, it can get tricky. So let's just as actually, we haven't mentioned low code. What are some strengths? I mean, to be honest, I would say that low code is probably the worst of all options because in your. In my honest opinion, it means that if you're going low code, that means you're probably not a technical founder or you don't have the technical enough technical skills to actually go pro code. And going low code typically means trying to build things that you're 100% not going to understand in full detail, which is going to lead to eventually tech debt. And you're going to be building Frankenstein applications and software that.

That's hard to sustain, it's hard to maintain and maintain. It's hard to pivot. You know, I think that maybe that the ability to change is undervalued by people when they start off with a product. What do you mean change the concept that you may want in a brief amount of time to actually make a pivot, to make a change towards a new way of doing things that requires restructuring your data, that requires changing your user interface. It may even require thinking about new problems that you weren't originally trying to solve. That ability is so powerful for a founder. When you have no code tools like Bubble, it's relatively easy to make an important pivot in your business and continue to move forward. That is an undervalued proposition that most people don't talk about, but it is important.

So as a recap, let's just do, let's just run really quick when to use no code versus when to go big and invest in something custom developed.

So I'll give you an example. In one of our applications, which is Zircles, there are aspects of the application that we have not built in bubble, okay? The 95% of the structure of the application is built in bubble and it works in bubble. But there are aspects of the daily payroll and other backend functions that at the time at least the only efficient way to resolve them was to build traditional code and integrated into the bubble application. And so we did that. And so there are some headless functions that run on Amazon that are built in traditional code. And sometimes that is the best solution for a specific functionality that may be difficult to build in bubble or maybe expensive to pay Bubble all of the workflow units to do it because it has to make a lot of know processes and runs and recursive calls and, and sometimes that is a, an architecture decision, but it makes sense to, to make.

It's not often that we gotta go through that where we need to go outside of bubble to get something built.

In this case, it was some specific web 3 functionalities that are complex.

It was techn. It was technical.

Yes, it was. But that is also one of the important aspects of having a good partner for your journey with bubble, because you have to pick and we're able to give you good advice and say, hey, maybe this specific function, we should consider doing it outside of bubble and integrating it with bubble and having that ability is, can be something useful in your toolbox.

Let's talk about some myths around scaling and building using no code platforms. The first one that I can probably think of is the one that always keeps popping up on Twitter or X, which is that you can't scale no code platforms. You can't scale a bubble application, for.

Example, and the people that are always saying that are traditional developers. I wonder why that's just not true. It's a myth. And when it's told maliciously, I would even say it's a lie. You can scale bubble applications, you can scale them to millions of users.

There will be costs involved, obviously, but the most important things are understanding bubble and how bubble works on a deep level. So that means having a good bubble expert by your side. But it's perfectly doable.

And at the end of the day it really is a question of look, you can scale if you build it right. If you don't build it right, then you're not going to grow because.

But I'll tell you that that's true with any development, any software development. If you don't build it right, it won't scale. If you build a crappy application and you develop it with over a year's worth of time with traditional software developers that just aren't up to par, then you're going to end up with a pro code application application that won't scale and this is going to be more expensive.

How do you build a future proof bubble application, one that can scale, one that you can be rest assured that hey, I'm not going to bump into issues when I hit 50,000 users.

It starts with a database.

Okay.

It's then it's followed by.

Thinking carefully about how you structure your workflows so that the most labor intensive parts are done on the server and not in the user's browser. Those are probably the two biggest things. There are a lot of optimization things like fonts and images and you know, sort of under the covers technical stuff that needs to be done. But the two biggest ones are.

Database and privacy rules that go together and workflows. How do you structure your workflows?

Well, I'm pretty sure that. Well, I think you did forget to mention having a vision. It's probably starts with a vision of.

Where you want to go, obviously. No, no. Why you're doing what you're doing.

How important are the wise?

The whys are everything. If you don't know why you're doing something, don't do it. If you actually have to stop and ask yourself repeatedly why am I doing this? Maybe the better question is could I just not do it? I really love that Alex or Mosey when he says that it's not what you do, it's what you choose not to do that makes all the difference. It's what you take off your plate so that you can actually focus on the important things that lead you to success. And that's true of a software development project as well and a bubble application just as much. Those are kind of eternal truths that aren't going to go away.

Well, I think that, you know, before we wrap it up, I think it's just as a call to action for everyone watching. Just think about your own goals, think about where you want to go, why you're considering building an app. You know, we've given you the pros and the cons of going no code, going pro code, why you probably don't want to go low code.

I would say be sure to go to ratio.dev and download our resource center, get access to it. It's free and it's got lots of cool stuff in there including vetted plugins that actually work and won't bloat your application down, lots of how to videos, great books to read, a couple of them even by yours truly.

Is it kind of presumptuous of me to say that it's a great plug. It's a great plug. All right, Ben, thank you for giving me permission.

I mean, I was just saying it's a great plug and we should actually, you know, it's about to go. We're about to list them so you can buy physical copies of those books and we should probably put them somewhere in these desks so people can see them. They're good books. If you're considering building an application in Bubble, those books are great books. Anyways, I think this is good for today's episode of no Codewistry. Again, the resource center is linked in the show notes. Go check it out, sign up. It's completely free and it's a pretty good, pretty good place for you to draw some inspiration from. Tutorial videos, podcast episodes, books by yours trilogy. Anyways, thanks for watching and we'll catch you next week.

Talk to you soon.