Building less: what real MetroPing users taught me

As more people started testing MetroPing, feature requests kept coming. Everyone had a different idea or problem they wanted the app to solve, and many of those suggestions were genuinely useful.

It was tempting to keep adding everything. Building a new feature can feel like visible progress, especially when a real user has taken the time to ask for it. But saying yes to every reasonable request is also how a focused product becomes a complicated one.

Sometimes the best feature you build is the one you decide not to add.

Every feature creates a long-term bill

A feature adds development, testing, battery and performance work, bugs to maintain, and another decision for the user. That cost continues after the first version works.

The question that changed my roadmap

I eventually started asking one question before building anything:

I even removed features that distracted people from the app's primary purpose. The result felt simpler because there were fewer decisions competing with starting a journey reminder.

User feedback still changed the product

Most feedback from the volunteer beta group I was working with was about UI and UX: clutter, too much information, dark mode, early permission requests, and unnecessary interaction. Some testers also reported battery drain.

That feedback was valid, and the interface is gradually becoming simpler. But a beautiful screen has little value if the alert is late, drains too much battery, or stops when the phone is locked. Accuracy, background reliability, timing, and battery therefore came first.

Focused growth fits a side project

Time and testing capacity are limited. More features can come after the core journey works reliably and the user base grows. Postponing an idea is not rejecting it; it is protecting what must succeed first.