I Built a Music Player Before Anyone Asked for One

I almost spent my whole weekend on a player nobody needed

Last November, I was in a small team café, trying to build a client a music player with more “feel.” Right after sketching the interface, I started obsessing over playlist syncing, lyric matching, and admin tools. I nearly forgot the first question: would the client actually open it every day?

I got stuck there too: the idea that more features automatically made a tool more valuable. Looking back, what slowed us down wasn’t the technology; it was failing to define the use case first.

What this method is, and who’s using it

Ali Chraghi, the article’s author, puts it plainly: don’t start with the player. First, work out what people want to listen to, when they listen, and where existing tools fall short. My friend Xiaolin Lin is a freelance photographer in Hangzhou who shoots product images for brands. While editing videos, she often needs background music. Instead of developing new software, she tested whether clients would save a fixed playlist using an existing player. Once people voluntarily returned to use it, she had a programmer add one small feature.

This isn’t “don’t build a product.” It means putting development after validation. The same approach can work for course materials, client deliverables, or organizing personal IP content: run the workflow with existing tools, then decide whether building something custom is worth it.

What it costs to replicate this today

Money-wise, I could start with a free tier or an existing tool costing a few dozen dollars a month. The time cost is one day: choose a real scenario and map the workflow on three pages. The technical barrier is modest, but it requires some basic computer skills. The first step is to open the music or file tool I already use, create a real playlist or folder, invite one client to try it, and record whether they come back a second time.

I also made the mistake of building first and finding users later, which is how the feature list kept growing. If testing now isn’t possible, getting my service delivery right still comes first.

A lightweight suggestion for each stage

When I was just starting, I would use an existing tool rather than rush to build a full product. With one or two clients, I’d test one concrete need and track the actions they use most. When scaling, I’d hand repeated workflows to a developer or automation tool instead of making everyone copy them manually. Not everyone needs this tool; I’d confirm the problem exists before investing in a solution.