When I started building my app, I thought making it better meant adding more features.
So I kept adding them.
AI pose detection.
Motion trails.
Movement analysis.
Scoring.
Radar charts.
A-B looping.
Chapters.
Annotations.
Video editing tools.
Every new feature felt like progress.
But eventually, I realized something uncomfortable:
The app was becoming more powerful — and harder to use.
The App I Was Building
I'm an indie developer from Japan, and I started developing MoveMaster, a video comparison app for dance and movement practice, when I was 60.
The basic idea is simple.
You have a reference video — maybe your teacher, an instructor, or a performance you want to learn.
Then you have a video of yourself practicing.
MoveMaster lets you play them side by side or as an overlay, so you can compare timing, posture, movement, and other differences.
At first, I thought:
If comparison is useful, more analysis must be even more useful.
That assumption led me to build more and more tools around the core experience.
Technically, I was proud of what the app could do.
But that wasn't the same as making a good product.
Then I Talked to Real Users
One of the most important conversations I had was with a ballet teacher.
Instead of asking him whether each feature was useful, we talked about what actually happens when people practice.
His feedback changed the direction of the app.
For dancers, one of the biggest problems is often much simpler than AI analysis:
Timing.
If the teacher's video and the student's video are playing at slightly different points in the music, comparing their movements becomes difficult.
So what really mattered was:
- Load the reference video.
- Load your own video.
- Align their timing.
- Play them together.
- See the difference.
That's it.
He also pointed out something I had gradually stopped noticing.
There were too many controls on the screen.
I knew what every button did because I had built them.
A new user didn't.
That difference is enormous.
Features Can Become Developer Bias
As developers, we spend hundreds of hours inside our own products.
A feature that feels obvious to us may be completely confusing to someone opening the app for the first time.
And there's another trap.
Once you've spent days implementing something, removing it feels painful.
You think:
"But this took so much work."
That's developer logic.
The user doesn't care how difficult the implementation was.
They care whether it helps them accomplish what they came to do.
I had to accept that some technically interesting features were making the product worse.
So I Started Removing Things
I redesigned MoveMaster around a much simpler idea:
Compare first. Analyze only when needed.
I removed or de-emphasized several things.
For example, I removed the 100-point scoring system and radar chart.
They looked impressive, but I wasn't confident that a number like "82 points" actually meant something useful to a dancer.
If I couldn't clearly explain why someone received 82 instead of 76, should the app really present that number as if it were objective?
I decided it shouldn't.
I also simplified the interface, reorganized the controls, and made the video comparison workflow much more central.
The goal became:
Open → Compare → Align → Play
Rather than:
Open → Choose from a large collection of analysis tools
Here's how the interface changed.
Before and after: I reorganized the interface to make essential controls easier to find. Some advanced features are still available, but they no longer dominate the experience.
This sounds obvious now.
It wasn't obvious while I was building it.
Removing Features Helped Me See What Was Actually Missing
Something interesting happened after simplifying the app.
Once the unnecessary complexity was reduced, the next important feature became much clearer.
Many dancers practice by watching videos on YouTube.
Previously, they had to prepare a reference video separately before comparing it with their own practice video.
That was friction.
So I added a new workflow:
YouTube reference video + your own practice video
Users can now open a YouTube video in MoveMaster and compare it with their own recording.
But that wasn't the end of the story.
The First Version Wasn't Good Enough
After releasing the YouTube comparison feature, I started hearing from users.
They liked the idea.
But there was a problem.
Aligning the timing between the YouTube video and their own recording was difficult.
They could adjust playback positions manually, but finding exactly the same moment in two different videos wasn't easy.
One user told me they had tried several times but still couldn't get the timing right.
That feedback made me realize something important.
I had solved the problem of accessing the reference video.
But I hadn't fully solved the problem of comparing it.
So I went back to development.
A Better Way to Synchronize Videos
I created a new workflow called 2-Step Point Sync.
Instead of trying to align two videos through repeated manual adjustments, users can now select corresponding moments in each video.
For example:
- Pause the reference video at a recognizable movement or musical beat.
- Set that moment as the master point.
- Find the same movement or beat in your own recording.
- Set that as the self point.
- Use those two points to align the videos.
The new 2-Step Point Sync workflow lets users select matching moments in the reference and practice videos.
The idea is simple.
Find the same moment in both videos, and use it as the reference for synchronization.
This doesn't automatically analyze every movement or guarantee perfect synchronization.
But it gives users a much clearer way to establish the starting alignment.
After synchronization, they can return to the comparison screen and study the differences between the two performances.
Comparing a YouTube reference video with a practice recording after aligning their timing.
This improvement came directly from user feedback.
And it reminded me of the lesson I had learned when simplifying the interface.
The goal isn't to build more features. It's to remove the obstacles between users and what they want to accomplish.
Sometimes that means deleting features.
Sometimes it means building something new.
The important thing is understanding why.
"More Features" and "More Value" Are Not the Same Thing
This experience changed the way I think about product development.
Before:
What feature should I add next?
Now:
What is stopping the user from doing the thing they came here to do?
Sometimes the answer requires new code.
Sometimes it requires better UI.
Sometimes it requires deleting code I already wrote.
And sometimes it requires rebuilding something I thought was already finished.
Surprisingly, deleting can be the hardest part.
Not technically.
Emotionally.
Because every feature represents time, effort, debugging, and learning.
But users never see those hours.
They only experience the final product.
I'm Still Learning This
MoveMaster is still a small indie app.
I'm developing it by myself, listening to users, changing things, occasionally breaking things, fixing them, and learning what actually matters.
I started this project at 60.
I don't have a large development team, a UX department, or a marketing department.
In some ways, that makes talking directly to users even more important.
A single conversation can change weeks of development priorities.
And I've started to think that this may be one of the biggest advantages an indie developer has.
We can change direction quickly.
We can talk to someone today and redesign something tomorrow.
We don't have to defend a roadmap just because we wrote it three months ago.
The YouTube synchronization improvement is a recent example of that.
Users struggled with something.
I listened.
Then I changed the app.
I'm sure there will be more things to improve.
And that's okay.
My Biggest Lesson So Far
If you're building your own app, especially as a solo developer, it's very easy to fall in love with features.
Building things is fun.
Removing them isn't.
But sometimes the best improvement isn't adding another feature.
It's discovering what your users actually came for — and getting everything else out of their way.
For MoveMaster, I'm gradually discovering that the core isn't AI, scoring, or having dozens of tools.
It's much simpler:
See the reference.
See yourself.
Match the timing.
Notice the difference.
Practice again.
Everything else has to earn its place.
And I wish I had understood that earlier.
I'm building MoveMaster as an independent developer in Japan.
If you're interested in the project, you can find it here:
App Store: https://apps.apple.com/app/id6759160605
Project website: https://taka0918.github.io/move_master_docs/
I'd also love to hear from other developers:
Have you ever removed a feature you spent days building because users didn't actually need it?
Or have you ever discovered that the feature you thought was finished still needed a complete redesign?
I'd love to hear your experiences.