Eighteen months of building Digging Music
I spent about a year and a half building Digging Music, a music wiki and community service centered on music discovery, lyrics, reviews, and interpretation.
When I first started, I thought it would take two months.
The plan felt simple in my head. If I designed the service clearly, I thought I could quickly build what I imagined, release it, get feedback, and maybe even watch it spread if I was lucky.
Reality was different.
The hardest part was not making the first version. The hard part was adding details, deciding what to remove, rebuilding things that turned out to be wrong, and learning that a real service is made from countless tiny choices and failures.
Looking back, much of the first year eventually collapsed. The truly meaningful work happened mostly in the final six months, when the direction became sharper and the product finally started becoming real.
This post is a reflection on the lessons I learned through that process.
A large imaginary world keeps you moving
At the beginning, I think it is important to let the idea expand.
When I first started working on Digging Music, I tried not to limit the size of the world in my head. I did not only think about specific features or implementation details. I kept asking bigger questions.
What if this changes how people listen to music? What if lyric annotations become a real Korean music archive? What if Digging Music can eventually provide lyrics or interpretation data to streaming services?
Most of those ideas were too large for the first version. Some were unrealistic. But they mattered because they gave the project emotional size.
Without a larger world, small tasks become exhausting. A button, a permission rule, a search page, or a review UI can feel meaningless if it is not connected to something bigger. The imagined world gave me a reason to keep working for 18 months.
A product needs a kick
A service needs a core reason to exist.
In the cooking show Culinary Class Wars, chefs often talk about a "kick": the one strong element that makes a dish memorable. I think products need something similar. A product can be polished, but if it is basically a weaker version of an existing big-company service, people have no reason to remember it.
For Digging Music, the kick was clear.
It was a Korean version of the Genius-style annotation experience: a structure where people can add explanations directly to lyrics, songs, albums, and artist pages. It was not simply a content database. It was a wiki-based system where people could add interpretations and build context around music.
That Korean-language gap felt important to me. English-speaking music culture already had many lyric explanations and annotation communities. Korean listeners did not have the same kind of well-organized archive. I wanted to fill that gap.
That was the reason Digging Music had to exist.
After expansion comes simplification
At first, it is useful to expand the world. But after that, almost everything has to be cut.
I originally imagined an autonomous system where users would edit documents, review each other's edits, earn points, gain permissions, and collectively maintain quality. It sounded beautiful as a system. In reality, it was far too early.
I worried about user moderation before there were users. I designed edit conflict prevention before multiple people were editing the same page. I thought about image optimization while the server was barely being used. I imagined vandalism review systems when getting even one real edit was already valuable.
Those were not real problems yet.
This became one of the biggest lessons: without real users, most product decisions are guesses. Some guesses are necessary, but spending too much time solving imagined problems slows everything down.
Simplification was not giving up. It was the act of protecting the core.
Ideas are not stolen that easily
At first, I was afraid to talk about the idea.
I thought Digging Music was special, and if I explained it too openly, someone might copy it. But after working on it for a long time, I realized that this fear was mostly useless.
Most people do not move just because they hear an idea. Even if they find it interesting, execution takes too much time, energy, and persistence. Also, the original idea almost never survives unchanged. The product I launched is very different from the product I first imagined.
An idea belongs less to the person who first says it and more to the person who keeps shaping it through reality.
Now I think sharing ideas is more useful than hiding them. Talking brings feedback. Feedback changes the idea. The idea becomes stronger through contact with other people.
The real competition is not who thought of it first. It is who keeps going.
Users are the best debugging tool
At first, I tried to find every possible issue by myself.
I checked the site, imagined edge cases, and tried to prevent problems before they happened. This felt responsible, but it was not efficient. As the product became more complex, the number of possible bugs became infinite.
The real change happened when I started working with a small group of supporters.
Once actual people used the service, real problems appeared immediately. The bugs were not the ones I had imagined. They were the ones that mattered because they blocked real users from doing real things.