DEV Community: TAKA RamBoo

I Removed Features From My App After Talking to Real Users

TAKA RamBoo — Sun, 11 Oct 2026 13:00:00 +0000

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.

I Released My First iOS App at 60 — Here’s What I Learned as a Solo Developer

TAKA RamBoo — Wed, 16 Sep 2026 13:00:00 +0000

Hi, DEV Community!

I'm a 60-year-old solo developer from Japan.

I'm not a professional software engineer.

My day job is in general affairs at a waste collection company, where I handle things like payroll, social insurance, workplace accidents, and internal computer systems.

Over the years, I experimented with VB6, Kotlin, Flutter, and other technologies — usually learning whatever I needed as I went.

And in August 2026, at the age of 60, I finally released my own iOS app on the App Store.

It's called MoveMaster AI Dance Analyzer.

And recently, it passed its first 100 downloads.

For many developers, 100 downloads may sound tiny.

For me, it meant something much bigger.

It meant that something I had imagined, designed, struggled with, built, and released by myself had actually reached 100 people.

Why I Built MoveMaster

I've been involved in street dance for many years.

When practicing dance, I often had this experience:

"I'm doing the same movement as the instructor... so why does mine look different?"

AI pose visualization and motion traces help reveal how the movement changes over time.

You can watch yourself in a mirror.

You can record yourself on your phone.

You can watch the video again and again.

But sometimes you still can't figure out what is actually different.

That became the starting point for MoveMaster.

Instead of simply watching practice videos, I wanted a tool that could help dancers see the difference between movements.

So I started building one.

What MoveMaster Does

MoveMaster is a video analysis and practice app for dance and sports.

Some of its features include:

Side-by-side video comparison
AI pose / skeleton visualization
Automatic synchronization
Slow-motion playback
Mirroring
Motion traces
Body alignment guides
A/B repeat
Music waveform display
Practice tools for memorizing choreography
Video annotations with text, lines, and arrows

AI pose visualization and motion traces help reveal how the movement changes over time.

The latest feature I added is Annotation.

For example, instead of thinking:

"Something looks wrong here."

you can pause the video and write directly on it:

"My center of gravity changes here."

or:

"This arm starts moving too early."

You can draw directly on the video and leave visual notes for your next practice.

The idea is simple:

See → Notice → Record → Practice → Compare again

I'm especially interested in how technology can help turn vague physical sensations into something we can actually observe and learn from.

Building It Without Being a "Real Engineer"

One of the biggest psychological barriers for me was this:

"I'm not a real engineer."

I didn't have a computer science degree.

I didn't spend my career at a software company.

There were many things I simply didn't know.

So my development process often looked like this:

Have an idea.
Try to implement it.
Fail.
Search for the reason.
Ask AI.
Try again.
Break something else.
Fix it.
Repeat.

Not exactly elegant. 😅

But something interesting happened.

AI dramatically changed what I could attempt as an individual developer.

Instead of stopping at:

"I don't know how to do this."

I could continue with:

"I don't know how to do this yet."

That difference was huge.

AI didn't magically build the product for me.

I still had to decide what to build, understand the problems, test ideas, fix bugs, rethink the UI, submit the app, deal with App Store requirements, and keep going when things didn't work.

But AI shortened the distance between an idea and an experiment.

For someone like me, that changed everything.

Then I Turned 60

In Japan, 60 is still an important milestone in working life.

My employment situation changed, and my salary dropped significantly.

So I had to think seriously about what I wanted to do with the next stage of my life.

One option was simply to accept that things would gradually get smaller.

Less income.

Fewer challenges.

Fewer new things.

I decided to try the opposite.

I wanted to build.

I wanted to learn.

And I wanted to see whether a small app made by one person in Japan could reach people around the world.

That's one reason MoveMaster now supports 18 languages.

I don't know how far it will go.

But that's exactly why I want to try.

The First 100 Downloads

MoveMaster recently reached its first 100 downloads.

It's not a viral success story.

There was no huge launch.

No massive advertising campaign.

No famous influencer suddenly promoting it.

I shared it with people I knew.

I wrote articles.

I posted videos.

I talked to dancers and instructors.

I kept improving the app.

And little by little:

1 download.

Then another.

Eventually, 100.

That number taught me something.

My first milestone: 100 downloads on the App Store.

The first users don't appear because your app exists.

You have to keep finding ways to communicate why you made it and who it might help.

I'm still learning how to do that.

My Next Challenge: Shipaton 2026

Now I'm taking on another challenge.

I'm entering Shipaton 2026, organized by RevenueCat.

Honestly, entering an international app competition at 60 wasn't something I imagined myself doing a few years ago.

But that's part of the fun.

MoveMaster is already released.

Real people are using it.

I'm still improving it.

And now I want to see how far I can take it.

Why I'm Writing on DEV

Until now, most of my writing has been in Japanese.

But MoveMaster supports 18 languages, and I realized something:

If I want my app to reach the world, I also need to step outside Japan myself.

So this is my first post on DEV Community.

I'd like to share what I'm learning about:

Solo app development
Flutter
AI-assisted development
App Store releases
RevenueCat
Video processing
Building products from your own hobbies and problems
And starting a new chapter as a developer at 60

I still have a lot to learn.

But maybe that's the point.

You don't have to know everything before you start building.

Sometimes you build because you don't know what's going to happen next.

And at 60, I think that's a pretty exciting place to be.

Thanks for reading.

If you're also building something on your own — especially if you started later in life — I'd love to hear your story.

MoveMaster AI Dance Analyzer

Available on the App Store.
Built in Japan with Flutter, and available in 18 languages.

App Store:
https://apps.apple.com/us/app/movemaster-ai-dance-analyzer/id6759160605