A few weeks ago, we posted on Twitter that we, Flywheel Studio, migrated a client from a #No-Code app to a custom app (more on this later).
It was a popular post and we wanted to share the lessons we learned. It’s related to a question that we answer on almost every sales call: “What happens when I need to move to a custom (code) application?” So, here are the pitfalls we encountered.
Note: this isn’t about the pros and cons of Adalo, FlutterFlow, NoCode, or code. It’s about the transition and migration from No-Code to low-code.
The story begins over a year ago. A prospective client, a Boston-based startup, approached us with a request to build an app similar to a local delivery service on Adalo. The timeline was tight. They needed it in a month for an important launch event. And, there was a catch:they were already planning to migrate to a custom code solution, but it wouldn’t be ready in time for the event.
We developed the entire application on Adalo, which was phenomenal for the time to market and the platform’s built-in features. Over the next year, we continued working with the client, but were constantly hitting capability issues, mostly around backend functionality.
Throughout that year, the client’s custom app plans fell through and they engaged us in migrating them to a better solution. We picked FlutterFlow.
In case you aren’t familiar with FlutterFlow or Adalo, here’s a breakdown of each:
- Adalo is a React Native mobile application builder with a WYSIWYG (What You See Is What You Get) drag-and-drop editor. It has a built-in backend database that’s similar to SQL.
- FlutterFlow is a Flutter web and mobile application builder. The editor is closer to Webflow and the backend is Google’s Firebase platform, a NoSQL database. We also used Google Cloud functions.
Okay, let’s get into the lessons learned. There’s a lot of overlap here too, but we’ve bucketed it as well as we could. We’ve also tried to order these by when we hit them, which is following the standard deployment cycle. So please note, they aren’t ordered by pain/priorities.
The first time we started to notice a significant difference between Adalo and moving to code was during testing. Everything took exponentially longer. And it wasn’t only in one small part of it–the time difference was pervasive.
- Provisioning accounts took at least 3x as long and were prone to errors
- User feedback took longer than expected
- Debugging took 5x as long (at least)
- Patching bugs took 2x as long
While our debugging and patching speed was one of our major selling points before, it quickly evolved into quite a lengthy and detailed process. This is still very much a recurring pain we feel with every new deployment.
Admin Data Management
One of the biggest surprises we didn’t anticipate was how much changing data access was going to impact the admins.
If you aren’t familiar with Adalo (and even for those that are), Adalo has built a few key features around the database that make it significantly easier to use than Firebase. We didn’t realize how often our admins were using the raw Adalo DB to look up records, edit fields, extract tables, and even bulk upload records using CSVs.
Firebase doesn’t have these features.
In short, Adalo had a lot of built in database features a traditional database doesn’t have. We had to build these from scratch, adding an entirely different development dimension we hadn’t previously considered.
One of our points of pride and a favorite part about using Adalo was our iteration speed. Fixing bugs and adding new features took minutes. When we received a bug report, we could debug, fix, and ship a new version in under an hour (ask a traditional development team what they think about that). It was amazing and clients loved it as much as we did.
When we moved to code, iteration speed dropped exponentially. Things that used to take minutes now take hours and days. That’s also a reflection of our new app’s complexity and the platform we’re using, so there’s a good reason behind this. However, when you’re used to true No-Code development speed, going back to normal development times is hard.
What should you learn from this? Here are our key takeaways:
- First, one of our biggest recommendations is not to move from No-Code unless you absolutely have to. In the end, our project would’ve moved regardless, but we know of several other projects that have considered the move and we can definitely go back to them and advise against it.
- Secondly, understand how your team uses the platform you’re on (in this case Adalo) and what they like and dislike about it. We really skipped that part because we were so focused on the user application that we didn’t consider how our client was using Adalo and whether they’d get the same experience in FlutterFlow.
- There’s a lot to be said for sticking with what you’re familiar with. With Adalo, we were using a SQL-like backend. If we had stuck with an application that had a similar backend structure, it probably would’ve been easier for our team and client to make the transition. Major changes are hard, especially going to a NoSql which for our client made NoSense.
Our move to code came with a lot of lessons learned the hard way. Before the migration, we did a lot of careful planning and worked through and tested our assumptions. We missed a few things that in hindsight were at least semi obvious. This leads us to believe that we were taking a lot of No-Code features for granted, something most of us probably do.