How to modify, enhance or fix someone else's bubble app - sharing my experience

Are you modifying, enhancing, fixing or rebuilding someone else’s bubble app?

Recently, a Client had an app that needed to be finished, and also had some bugs to be fixed. I cannot name the Client because I maintain confidentiality, even in the absence of a NDA. Their current app was over a year old, and quite successful in their industry. Now, the app was being enhanced with many new features, incorporating learnings from users, and featuring a brand new look. This V2 app was the next step in the evolution of the vision of the founders.

But there was a problem - the current developer didn’t have enough time to continue working on the app and the Client wanted someone to take the work-in-progress app across the finish line.

Herein lies a fact of the software development industry - Agencies will not touch anyone’s existing app. The potential headaches are enormous - things like faulty data structure, inefficient workflows, improper naming, performance issues, etc. More importantly, learning and understanding someone else’s code (or nocode!) is not fun and can be quite stressful. The time spent studying an app, and guessing why certain things were done a certain way can be a huge undertaking. And above all, agencies don’t want to take responsibility for the work done by someone else - and that is the right approach. Having run an Agency in a previous life, I know the challenges involved only too well.

But in this case, the Client didn’t want to rebuild the app from scratch, which is what most Agencies were offering to do. Throwing away all the work they had already put in wasn’t an option.

I took on this nearly impossible task of studying, enhancing and repairing the app, which was a single page application that contained hundreds of workflows and a few thousand elements. This was a fairly large project and took nearly 100 hours of intense work to complete.

In this post, I want to share my learnings with the bubble community on how I went about completing this project to the satisfaction of the Client.

  1. First of all, I spent enough time (around 10% of the total) reviewing the app and writing high-level documentation before any changes were made. It was well worth the investment, which paid off handsomely on this project.

Took the time to document issues and possible fixes for:

  • Data structure
  • Page structure and UI
  • On page workflows
  • Backend workflows
  • APIs
  1. Created a Save Point before starting, and once I started, I created frequent save points whenever I crossed a milestone or had a change that was tested and working well. This allowed me the comfort of returning to a prior point in the app’s development.

  2. Asked the Client to create a copy of the app, and provide read-only access, so I could refer to the original app at any time, without having to revert back to a save point.

  3. I kept fields that were to be deleted intact, and renamed them with a prefix (e.g. DEPR) to indicate that the field is going to be deprecated. Deleting fields without altering workflows will only lead to trouble. Renaming them, however, causes the new name to appear in workflows which can be modified or deleted as needed.

  4. When it wasn’t possible to use existing workflows, I created a copy of the workflow, and diverted the functionality to new pages or groups, as the case may be. Later, I went back and deleted redundant workflows that were no longer needed. Then I also deleted groups or pages that were no longer required.

  5. For old pages and groups that were being retired, I changed their background colour to a bright red, to make them highly noticeable just in case they were shown by a rogue workflow during testing (and some did, which I caught and fixed).

  6. I tested, and tested and tested and tested. Every time I tested, I would delete test records that were created by a previous test. I have found that leaving test data in the database, especially if it was created incorrectly, always causes issues and confusion. This is because we tend to forget our testing sequence and then wonder how erroneous data got into our database.

  7. Since the app had 3 user types, I used 3 browsers simultaneously and logged in as one user type in each window, while running tests along the path of the most common user journey. Doing this allowed me to see all 3 user experiences in tandem and validate if data was updating in all 3 windows as expected. As an example, the messaging capability of the app had some issues and by viewing 3 user types logged in on one large screen monitor, I could test and debug this much quicker.

  8. Before making drastic changes, I made short loom videos for myself (and many times, for the Client), capturing the current state of the app and outlining the changes I was about to make. This video documentation proved to be invaluable and saved me on more than one occasion.

  9. For complex logic, I wrote out a decision table (using notion) to cover off each of the use cases, and described the logic that would apply. At times, I resorted to write out complex logic using pen and paper and that really helped save a ton of time when actually building the logic in workflows. Had I gone straight to the bubble editor, it would have taken much longer to figure our these complex pieces of the app.

The technical aspects of refactoring an app is just one side of the coin. The other, and perhaps even more important aspect is communication. Meeting with the Client periodically, providing updates and setting the right expectations are just as important as doing the work.

Here are my learnings in that area:

  1. Build trust. This is the most important thing you will ever do with a Client. Actions speak louder than words - do what is in the best interests of the Client at all times.

  2. Communicate frequently with the Client, listen carefully to their needs and set a regular schedule to meet. I recommend meeting every day for large projects, or at least 3 times a week for smaller ones.

  3. Especially when billing on an hourly basis (like I do), it is important that the Client trusts that you will be accurate and fair in how you report on time. For example, I don’t bill trivial time spent on email or Slack, or reading and responding to a question from the Client. After all, I am a bubble developer, not a lawyer. I also don’t bill the Client for small amounts of time spent ruminating or mulling options when tackling a particularly challenging part of the app.

  4. I took meticulous notes during all meetings to ensure that we were all on the same page. At the end of the project, I turned over all documentation and these notes to the Client. I love adding value wherever I can, and the Client was really happy that I went the extra mile.

  5. Help the Client understand why it is worth spending time to learn what the app is doing, and how this investment will eventually lead to a better (and less costly) outcome for the Client.

Of course, it takes a reasonable Client to make this entire process work and I am thankful to have had not just a reasonable, but a very understanding one (I hope you’re reading this!).

My hope is that this post is useful to some folks. Please let me know in the comments if it was, or even if it wasn’t. As much as sharing my experience, I would love to learn from yours.

Happy bubbling!

14 Likes

Thanks for sharing these thoughts out. Very good read.

1 Like