From our experts: Low-code vs. Custom build

Ringo sat down with Tristan Drummond, our Low-code Team Lead, and Alexia, Head of Engineering, to chat about the pros and cons of using low code, as well as how we strategically leverage both of these to build successful ventures at The Delta. 

Find out what Alexia and Tristan think of drawing a line between low code and high code builds, when it’s best to use one over the other, the cost-factor of each of them and if ventures can ‘outgrow’ low code.

Ringo:
So the first question I have for you, Tristan, in your opinion, when it comes to looking at a custom build [when compared to a low code build], where do you draw the line?

Tristan:
Yeah. Well, I mean, this question changes. I mean, the answer to this question changes almost on a month to month basis these days. 

You've got so many companies that are pushing the edge, pushing the limits, and we try to stay at the cutting edge the whole time. So we monitor hundreds of low code tools. And like when I started the low code team two and a half years ago at [The] Delta, we couldn't do half of the local builds that we've done in the last three months. 

I think where I draw the line is if you have limited resources, so we have limited money, you have limited time, go look at almost everything. If you have unlimited time and unlimited budget, I'm just going to say that this is not where we specialize. Go do something custom, like get the best tech in the world, take all the time you need, get incredible devs to do it over two years. Spend 10 million dollars, that’s great. 

That’s not where we specialize. We specialize in fast and cheap and iterative so you can find your value proposition, get traction. 

Ringo:
Don't you think that if you're going fast and cheap, you're losing out on a lot of finesse, and you could potentially lose out a lot of customers? 
And you're actually going too quickly, you're moving too fast, and you're not actually able to build the product that you want to.

Tristan:
Yes, I think that's where the mindset of how you approach low code comes in. And if you apply an engineering mindset, you ensure that there's still quality in so that you like looking after your customers and building according to their needs. It makes a big difference. 

I think low code has way more potential for abuse than full code because it's really easy to build stuff, which means it's really easy to build low quality, like terrible apps that don't scale on low code.
‍

But if you apply engineering thinking and you make the most of the capabilities that low code offers you, you can build something really top quality these days. But ten times cheaper, ten times faster.

Ringo:
Alexia, Where do you draw the line between low code and is it a definite line for you, or are you still unsure?

Alexia:
No. To me, it's pretty much - they're all talk. I mean, at the end of the day, what Trist said, like it's the mindset that actually matters. I disagree with the fact that it's cheaper to build low code, necessarily because it really depends on your own exposure, your own experience as a founder. You've got an idea, what you've been exposed to is essentially what you're familiar with is going to be the cheapest route most of the time, right?

And it's also going to be the route where you're going to be most confident and you're going to be most comfortable launching fast and launching to market immediately. If you're on a new platform, working with new tools, you're always going to be a little bit nervous, right? So pick the things you're comfortable with. The thing about drawing the line to me is there are very few situations where only low code will work or only full build will work.

It's really up to you and up to the industry that you're going to operate in. If you know from the get-go, if you can answer yes to any of those questions, am I going to be operating in a heavily regulated market where there's a lot of financial data that's going to be flowing through my system? Am I going to be working like processing high volumes of data from the get-go? Am I going to be working with very sensitive data or confidential data that cannot be shared? 

You probably want to ask yourself the question: Do I want to take the risk of using somebody else's code, essentially? Do I want to take the risk of choosing to/let my data transfer through somebody else's platform? Control is a bit of an illusion, though. 

So, the fact that you're going full code also doesn't guarantee that you own the data, that the data will always be in your control, but it will give you a little bit more visibility, right? Then you'll have someone to hold accountable, yourself, because you built it, you know the code. Or the person that you actually contracted to build the code for you to build the app for you, you'd be able to hold them accountable. It's a bit more difficult to hold people accountable when it comes to low code. 

Another thing to bear in mind is, you know, costing. There's always a cost attached, right? And the cost of rebuilding sometimes can actually be quite heavy if you know from the get-go. If your idea is actually quite complex, then you're going to need a lot of custom components.

You're going to look at the library of competence available on Flutter, for example, and you know that the things that you want from the get-go are not available. It takes a little bit more in terms of cost, actually a bit more to build custom in the low code platforms so the rest of your app will be cheaper, but it will take a little bit more expertise to actually get someone that knows the platform well enough to build your custom components that will work. 

In this case, it will be cheaper to build it yourself or to get someone to build it in high code. That’s what I think about costing and the original question. There is no line.

Trist:
One thing I didn't touch on, that I think actually is important besides having unlimited resources versus scarce ones, is how well-defined is the problem and what is the goal of the particular build that you're doing? Because, and the reason why I just sort of forgot about that or assumed is, is because everyone that comes my way doesn't actually know how well to find the problem.

It's like they still need to figure that out. And the goal of the build is to get something in users hands so that to understand the market, it's to find the product market. But it's a very early stage venture. It's guys who, like that much as they don’t have a clear idea in their heads what the process is, there's no real validation of that. It's not like they have an app that's already in 10,000 people's hands. 

My goal as a low code team is normally to get founders through the first 2 to 3 years of their world until they've got sufficient traction. They've got funding, they've got momentum, and then you've got revenue - you can quite easily justify spending a couple of million on it on a full build. 

Deciding when to build in low code OR full/custom/high code

Ringo:
All right. So on that, for example, I’m a founder and been running for ten years and I've got the cash I could create a custom-built, but I'm still opting in for low code, what are the risks that I'm taking where I mean, very clearly I've got the money very clearly. I should have a custom build at this point.  

What are the risks involved here? When I'm going low code? As opposed to custom? 

Alexia:
Look, I mean it really again, depends on how risky the business is, right? If you could stay with low code, there's nothing to say that low code is a tool that you only use as a prototype or for the first few phases of your venture. If the use case is fit for it, then there's no reason to move.

If you can't find a reason, if you're not hitting any limitations or any restrictions, there's no reason to move. Usually you grow out of it, right? That's when you know that you actually need to go full build. And you need to be able to actually kind of know where that line is, right? I need to scale more rapidly.

I'm starting to spend a lot more money on making things custom because, you know, everything that I'm actually churning out is looking a little bit vanilla, now. I'm trying to be more custom. I'm trying to give the customer a little bit more of a personal experience, so I have to put a lot more energy in. That's when you need to draw the line.

That's when you actually start considering rebuilding in full code or actually moving certain parts of your application into a full code, right? You also don't have to rebuild everything. You can actually keep your front end and low code and actually start like building a custom back end for it. That's an option. I just think about the things and think about the reason you want to grow out/ you want to move out of it. 

The reason you want to move out of low code is usually scaling, costing. It's becoming too expensive because it's way too specific and you have to spend too much energy to make things feel a little bit more personal, right? Or you know. Yeah. To simply - because you actually want to know, you want to tap into a completely different market, for example. 

You want to go native on the phone, right? You're not going to be able to do that with all Flutterflow. You're not going to be able to tap into the device itself to take control of the hardware, biometrics, these kinds of things. 

When you get to that level of maturity in your application and you want a little bit more control and you want to actually do a little bit more complex things, that's when you actually start growing out of low code. But for some ideas and some founders, this day might never come. Low code will just be the thing, or it will evolve fast enough to keep up with their needs.

‍