Choosing Bubble.io for the first version
In the early development plan for Digging Music, I decided to build the service with Bubble.io.
At that stage, the most important goal was not technical purity. I needed to move quickly, test the idea, and turn the concept into a working product without spending too much time on development environment setup, deployment, authentication, and infrastructure.
Bubble was useful because it was visual, browser-based, and fast to learn. Pages, database objects, workflows, login, and sign-up could be built through a GUI. For a first product, this speed mattered more than having full control over the code.
The advantages of no-code
The biggest advantage of no-code was speed.
I did not need to set up a local environment. I did not need to configure a backend from scratch. I could design screens, connect data, and build workflows directly in the browser.
This made it easier to focus on product structure rather than engineering setup. For Digging Music, that meant I could spend more time thinking about music pages, wiki structures, reviews, user flows, and database design.
The limitations of Bubble
The biggest downside was that I could not fully see how the system worked internally.
Bubble does not expose code in the way a normal codebase does. That makes development faster, but debugging harder when the platform behaves unexpectedly.
There were also moments where simple-looking logic required awkward workarounds. For example, referencing a previous index was not always direct. To use something like current index - 1, I sometimes had to place a hidden container, set its value to the previous index, and then reference that container.
Synchronization problems also had to be handled through similar indirect structures.
Most basic features existed, and plugins covered many missing pieces. I later found that even expression-handling problems could sometimes be solved with plugins such as math.js. Still, the important question became not only whether Bubble could do something, but how awkward it would be to make Bubble do it.
Localization and product polish
Another early issue was localization.
Bubble provides convenient built-in features such as login and sign-up, but some default warning messages appeared in English. For a Korean music service, this felt unfinished. A login failure message should feel native to the user, not like a leftover system default.
This was a small issue technically, but it mattered for product polish. A feature can work correctly and still feel incomplete if the language and interface do not match the user.
Community and learning resources
The Korean Bubble community was relatively small.
There were open chat rooms and Korean no-code resources, but the amount of information was limited. The official Bubble forum was much larger and more useful. Bubble staff sometimes answered directly, and most common problems had already been discussed there.
This made the official forum one of the most important learning resources during development.
What this plan meant
Looking back, choosing Bubble was a practical decision.
It was not the most flexible tool, and it came with invisible constraints. But for an early-stage product like Digging Music, speed mattered more than control.
Bubble let me build quickly and focus on the actual product: what the service should do, how users should move, what data should exist, and which features mattered first.
This was the beginning of Digging Music as a real product. It was also the first moment I clearly felt the trade-off between speed and control. No-code helps you move fast, but the boundaries of the platform eventually become part of the product design problem.