Why do Top Flutter developers stay away from no/low-code tools?

Nowa
8 min readSep 24, 2024

--

“Coding takes so long! I feel I am spending my energy on the wrong things!”

This is what came to my mind once back in 2015 when I was making mobile apps. I got so lost in the tiny details then that I forgot what I was building.

Many developers feel this way, but we still love to code in the end. Why is that? Even though our relationship with coding feels toxic, we can’t quit it in the end, it gives us freedom and power, so we overlook the hard parts.

I tried to fix this by looking at no-code and low-code tools, which let you build apps without much coding. But in the end, I didn’t use them and went back to coding.

These tools have obvious problems: they’re limited, not easy to use, and produce only simple, low-quality apps. But is that the only reason we avoid them?

I talked to many developers to find out why they stay away from no-code and low-code tools. I got some interesting ideas I felt like sharing.

As a context, we are building a platform designed for Flutter developers called Nowa, so we interviewed many developers to understand what’s on their minds. Even though we’re developers too, sometimes it’s hard to put into words why we feel a certain way.

“Real developers don’t use no/low-code tools”

I’ve often heard this from other developers. It might sound like pride, but when you look closer, it makes sense.

So, why do developers avoid no-code and low-code tools? Here are the main reasons I found:

The generated code is for the trash

When developers try these tools, the first thing they do is build something quick to see the code it makes. Their reaction is often, “What the heck is this?” They say that seeing the source code feels like a lie. Yes, you can see it, but you can’t understand it, can’t change it, can’t make it bigger. You can’t do anything except feel a bit better knowing you have the code, which beats the whole purpose.

The problem isn’t just that the code looks weird or doesn’t follow good practices. It also has “dependency hell.” Most of the code uses special packages made by the tool itself, making it impossible to work with. Your first thought is to replace it with something you know, but oh boy, how many things will break when you do that!

Performance is a big issue too. The code is not optimized at all, with lots of extra parts that slow things down.

It Forces You to “Think differently”

Even though “Think Different” was Apple’s slogan, it’s not always good.

As developers, we’re used to thinking in a clear way when building, so when things get bigger, we can still control them. For example, when working with an API, we might say, “I’ll make a service class that handles all the talking with that API, then I’ll use it in the main part to handle the business logic, then…”

Ideas like clean code, good structure, and keeping things simple are how we think when we build stuff.

We probably had to learn these the hard way after our first projects got messy due to bad code. That was when we decided to learn the right way of coding and organizing. But that’s what you won’t use when you use a no-code or low-code tool.

The way you make things work with these tools is different from coding, with ideas that feel weird and a bit scary because they don’t lead to a good structure. You hope the tool keeps everything neat behind the scenes.

But reality hits when you download the code and see your worst nightmares as a developer come true. Which leads us to the next problem:

Technical Debt and Scalability

Because of this different way of thinking, the code generated by those tools has a bad or no structure at all. Since you weren’t involved in organizing it, the code looks strange and hard to deal with, causing big problems that are tough to fix.

That’s why you hear developers say, “You can use no-code or low-code tools for trying out ideas and prototypes, but for building real products, forget about it!”

The trap with using such tools is that as your project gets more advanced, it becomes much harder to maintain. In the beginning, it all feels quick and nice, but very soon it gets messy and out of control.

I found out many teams had to throw away their whole work and start from scratch with pure Flutter code. It would be fine if that was their plan from the start — to build a prototype and then redo it — but they felt they were kind of “tricked” into believing what they were building could grow with them, and they put a lot of effort into it.

Giving Up the Usual Workflow

This is something that hits developers right away when using a no-code or low-code tool for the first time.

These tools usually make developers change the way they work by forcing them to use their platform most of the time. Even if it’s a Flutter project, your main tool becomes their platform.

You might find workarounds to include your favorite code editor or tools in the process, but in the end, everything goes back to their tool, and it stays as the main place for your work.

Since your project is always on their cloud, you always need a good internet connection to work. But with the original way of developing, you only need a laptop and a charger.

If a developer decides to switch back to their original workflow by downloading the source code and working with it in VS Code, for example, then that’s the end of your journey with visual building! You can’t go back and import your project there, so you need to be really sure you don’t want to return when you decide to use your own tools.

Never Full Coding Freedom

Some tools don’t let developers write code at all, which is a big NO-NO for developers. On the other hand, some tools allow writing custom code but only in certain places inside the project.

So developers can’t touch most of the project’s code and have to stay within certain limits, cutting down the freedom of what developers used to do when they were building things anywhere in the project, in any part they needed to work on.

How Are We Building Something for Developers?

At Nowa, we want to help developers work faster and build better products by focusing their energy on the right things. We do this without limiting your freedom or the ability to grow your projects.

Our upcoming big upgrade, Nowa 2.0, is built around three main ideas:

1. Building Functionality Visually but with Structure

Our visual approach is more like “visual programming” than just “visual building.” This means you’ll still handle important tasks like setting up structures and organizing your app, but you’ll do it visually in a simpler and faster way than typing out all the code.

Most importantly, the code Nowa generates will follow the structure you define. When you look at it, it’ll feel like you wrote it yourself — but in a fraction of the time and effort.

2. Hybrid Building Between Nowa and Your Original Workflow

We don’t want you to give up your favorite way of working that you’ve used for years. That’s why we’re making Nowa so it can work side by side with your preferred coding tools and IDEs.

Your Flutter projects are saved locally on your computer, not on our cloud or somewhere on the internet that you don’t know about. This means you have full ownership of your code and, can work offline as a bonus.

You can import your Flutter project into Nowa (as a desktop app) and open it in VS Code at the same time, working on them side by side.

For example, you might use Nowa to build a UI component visually, then jump to VS Code to use that component somewhere else in your code.

Or vice versa, you could build a feature that fetches data from an API visually in Nowa, then switch to VS Code to create a class that handles data in different ways, and then jump back to Nowa to use that class in the feature you’re building visually.

Any changes you make in Nowa will instantly show up in your codebase, which will also reflect in VS Code and vice versa!

This also means Nowa can import your existing Flutter projects. So if you’ve downloaded the source code and switched fully to coding mode, don’t worry — you’ll be able to find your way back! 😊

3. Figma-Like Experience in Designing

One problem development teams face is that developers spend a lot of time redoing UI designs that designers already created in Figma.

Designers don’t have other ways to create great UIs besides Figma, which only produces design mockups that still need to be coded.

So we’ve built our designer to offer a Figma-like experience that lets designers who don’t know anything about Flutter or coding build with the same freedom they have in Figma.

Now, developers can jump straight into building functionality since the UI code is generated automatically while the design is being created.

It’s like instantly turning your designers into designers and front-end developers too! (without paying an extra salary or dealing with communication problems ;) )

Want to give Nowa 2.0 a try?

Nowa 2.0 BETA will be released to a closed group of beta testers. If you feel like we’re doing something that can help you, we’d love to have you as one of the first people to try it out!

We’ll also offer a free premium version with all its power in exchange for your feedback. We’ll also work closely with you to build the app you want so you can get it out quickly!

Sign up here for early access — it’ll take you less than a minute, I promise.

Early access will be granted during the first week of October!

Feel free to share whatever you want with me at anas@nowa.dev

Some helpful links:

See you all soon!

--

--

Nowa

Nowa helps Flutter developers build stunning, scalable and production-level Apps faster by integrating creative visual building into their workflow