My first Bubble application I built back in 2022. What I actually learned.

Challenges

The application was developed for a French company as an internal tool to facilitate their day-to-day operations. Part of their job involved fixing non-conforming points on telecommunications towers already built (i.e. sites). These points prevent the tower from operating. Each site was received from the operator (their customer) as an Excel file with 4 tabs, dozens of rows, and even embedded photos for the non-conforming points inside the Excel sheet itself, with an empty place for a photo after resolving the issues of each non-conforming point.

They actually received hundreds of Excel sheets back then, where they had to work on each site, keep its Excel file updated, and then communicate all the updates to all the stakeholders, usually by email and recurring status meetings to follow up on progress.

It was clear that the amount of expected work exceeded the capacity of the team, and that was when I proposed getting all the data from Excel sheets into one centralized application.

It's worth mentioning that by this time, I had already started learning Bubble only a few weeks earlier, and I saw that this was a good opportunity for me to work on a real-world project and implement it on Bubble.

Solution

The first version was built in a matter of weeks, including migrating every site's existing data across, including photos. I can tell you that the migration alone was a project by itself.

It was far from perfect, but it worked, and it gave the team the chance to start managing everything from the application from day one. In fact, the first version went live before the project even started with the operator. It's still the app they use today. Small internal user base, does its job well, and they never needed to hire more team members.

One of the features that saved them time was quotation validation. For specific cases (above a certain quotation amount), a validation from the operator was required to approve the quotation and move forward with the project. I added this inside the application so that people responsible for quotation validation receive an email upon quotation creation with a link to the quotation to approve or reject it.

Results

Just bringing together all the data, processes and stakeholders in one place had a tangible added value:

• Stakeholders didn't need to contact the company to know about the progress, as they had access to the application based on their access level.
• Recurring status meetings were planned less frequently.
• The amount of work was delivered with the same team. There was no need to hire more team members or outsource part of the work.
• Inline comments in the application for every site kept things well organized and in context.
• Quotation approvals were faster.
• There were no version conflicts or questions like "where's the latest version?" since data was already centralized in the application with real-time updates.
• The dashboard gave everyone good insight into progress, with some level of drill-down and statistics.

What I Actually Learned (the stuff that mattered more than any tutorial)

I didn't try to perfect the first build.

I didn't have the luxury of getting it perfect. I had a deadline and a client waiting to get off Excel before his project started with the operator. Looking back, that constraint was a gift. The instinct to polish v1 before shipping is usually fear wearing a productivity costume.

I learned Bubble by building in Bubble, not by watching people build in Bubble.

Database structure, privacy rules, plugins, the Google Maps integration, API calls, backend workflows, etc. I watched a lot of tutorials. However, they really clicked from breaking things on a real project with real stakes and fixing them under pressure. I was watching tutorials only when I wanted to solve a specific problem in the application, rather than watching tutorials just for the sake of watching them. In other words, I was keen to keep my hands dirty.

Actually, I worked on improving the application in the background later on and even developed more features on top of the first version, and this was when I discovered what I did right and what I did wrong, so I was improving on the go. My database design was not efficient, the privacy rules were misconfigured, and I didn't put in place any design system but rather than that I was applying different styles to elements separately. I also don't remember using Reusable Elements. However, Workload Units (WU) weren't introduced in 2022, so at least that wasn't a problem.

Understanding what the client actually needs beats guessing what they probably want.

It's tempting to build the version of the app you'd want if you were them. That's not the job. The job is understanding their actual workflow well enough that the app disappears into it. That's how I always prefer to work. Engaging users is key, as I always think about user adoption from day one. By the way, I wasn't surprised at all when users asked for UIs similar to Excel files, as they were very familiar and attached to it. I mean, like, more than needed.

A customer can't tell the difference between a "good" app and a "bad" one, if both work.

Yes, that's right. Clean database architecture, elegant privacy rules, smart plugin choices, optimized WUs - the customer will never see any of that. They'll ask: does it work? Does it save me time? Does it break? That's the whole review.

This is not an invitation to deliver a low-quality product, but it's a point worth considering by customers themselves. Not everything that looks like it works is well engineered, scalable, performant, or well secured.

Agency tier means nothing.

Later on, I've worked on other Bubble apps delivered by high-tier Bubble agencies that for some reasons ship weak products. Meanwhile, I've seen solo builders ship things that quietly run for years without complaint. I believe tier badges measure the revenue an agency generates for Bubble, but they don't measure quality.

My Honest Advice

If you're early in your Bubble journey and stuck trying to make your first build "good enough" before shipping, that instinct might be the thing actually slowing you down.

Ship the version that works. You'll learn more from the post-go-live first weeks of real usage than from another 3 months of polishing something nobody's used yet.

If you're a customer looking for a freelancer or an agency to work on your Bubble project, please don't just look at the surface. Go deeper, and do yourself a favor by taking the time to make the right choice from the beginning.

I recently made the below video for this project (less than 2 minutes).