Can no-code apps really stand the test of time?
Our oldest no-code Bubble app turned 3 today: some learnings
On this day 3 years ago we went live with GlobeRelo’s project management tool. GlobeRelo is a 7 figure international move management company and the app is used daily by a team of relocation specialists in the Netherlands, Croatia, Ukraine and Russia.
We built the app with the no-code programming language Bubble. There have been a lot of ups and downs with Bubble over the last three years but I think our client gave the best compliment we could get recently when he said the app was a lot more performant than this time last year or the year before.
And that’s a compliment to Bubble really because we haven’t worked much on performance updates recently. It is a testimonial to the Bubble team and their continuous efforts behind the scenes to improve the platform’s stability and performance. Efforts that lead to their first funding round announced this week.
After three years of developing this app we learned a few things that we adopted in our way of working with all our clients and hold particularly well when developing with no- and low-code solutions.
Start with a solid and consistent base
We use our own Base to start new client apps. A Bubble foundational framework that is consistent across apps that makes it easy for us to work on multiple projects at the same time, onboard freelancers more quickly and above all, debug issues much quicker. It is a blank canvas on which we can create basically any design.
Focus on performance over form and sometimes even function
Nothing is more frustrating to the client and their users than an app that doesn’t work or works barely. We found out the hard way by focusing too much on form and function with some features.
A trap for GlobeRelo in the early stages was FOMO on critical data. Just because we had the means, we tried to capture a lot of data across different data types that ultimately needed to be aggregated into single tables. The data size, search constraints and filters killed performance and forced us to keep a simpler approach.
Start with something that performs, then slowly add more complexity and keep an eye on performance. If something is killing performance, strongly consider if it’s worth having.
It may help to keep away from the Bubble editor when designing new functionality and only implement it once you think you’ve got it. It keeps you from being tempted to jump in the editor and lose time tinkering around. (can be fun though!😁)
Stick to the plan
This is true for self builders as well as when working for a client. I fell in the trap early when I just discovered Bubble: the sky is blue and endless. You want to push the limits of Bubble and your own imagination and it is so tempting to add new functionality.
Clients are often the same. They say they need such function, it is business critical. Or worse, their clients feel they need a certain feature that will add enormous complexity to the app.
For GlobeRelo an important market is private people and on paper it sounded easy to add an external dashboard and onboarding sequence for those users and allow somewhat of a DIY international move. A lot of effort was put into this functionality but in the end the business focus shifted even more towards other types of clients and these features were more or less shelved.
Sometimes, it is about sticking to the plan and not divert. Is that functionality really critical for the first iteration? Is it worth the effort to add that feature at this point?
Sticking to the plan is sometimes the hardest thing to do, especially with Bubble’s endless blue sky
Work organized
We use our own project management tool with our clients in developing their apps. (or our own for that matter). We work in Sprints and have our clients (and us) add items to the project’s backlog. Each sprint consists of a number of items which go through different stages (submitted, assessed, queued, in progress, review and done).
At the end of the cycle we bundle all the items and put them in a version that we use when we push the app live. This allows us to keep track of all the items that have been pushed into a new version and can automatically generate a change log.
Keeping at least a simple change log will help you to keep track of what you’re working on and when. It saved me plenty of times when I was going to finally work on that one feature only to find out that I already did that the week before…
Keep the app safe and keep trust
In addition to starting simple, starting safely is hugely important. You may have a big problem when users can see other user’s data and it will ruin the trust you have with your client as well as their trust with end users. There is a lot said and even more to write about security and privacy rules, so that’s maybe for another time.
The biggest takeaway here: You can build apps to last built with no-code solutions
We often get questions about the longevity of apps built on Bubble. I think Bubble has proven to cope with that issue perfectly over the years. These are exciting times for no- and low-code enthusiasts!
Keep on building everyone! 💪
