Deciding What to Build Next Without Losing Focus

Once something you've built is actually out in the world and being used, a new problem shows up — one that's almost the opposite of the problem you had while building it. Before launch, the challenge is finishing. After launch, the challenge is deciding what deserves your attention next, out of a growing pile of requests, ideas, and half-formed opinions about what would make things better. This post is about how I approached that decision, and it applies to more than just apps — anyone maintaining anything that other people use will run into the same fork in the road.

The Trap of Saying Yes to Everything

After a month of specific, detailed feedback (which I wrote about in the last post), it would have been easy to turn that feedback into a long to-do list and start working through it top to bottom. That approach feels productive — you're responding to real requests from real users, after all — but it has a hidden cost. Every feature added to something small makes the whole thing slightly more complicated, slightly slower to maintain, and slightly further from whatever made it appealing in the first place.

I've watched this happen with other small tools and apps I've used over the years: a simple, focused product slowly grows a dozen features nobody asked for in combination, and somewhere in that growth, the thing that made it good in the first place gets buried. Saying yes to every request isn't generosity toward users — it's often a slow way of making the product worse for the people who liked it as it was.

Sorting Requests by a Different Question

Instead of asking "is this a good idea," which almost every suggestion can pass, I started asking a narrower question: does this request come from someone who's already using the tool the way it's meant to be used, or from someone trying to bend it into something it was never meant to be?

Requests from the first group tend to be small, specific, and aligned with the core purpose — a clearer label here, a faster way to see one piece of information there. Requests from the second group tend to be bigger asks that would turn a focused tool into a more general one. Both kinds of requests can be well-intentioned. But only the first kind tends to make the actual product better rather than just bigger.

The Feature That Came Up Repeatedly

One request appeared, in slightly different words, more often than anything else during that first month: a simple way to look back at recent activity rather than only seeing the current, live state of things. Several users independently described almost the same frustration — they'd glance at the app, see the present moment, and have no easy way to check what had happened a bit earlier without having kept a separate note themselves.

That kind of repetition across unrelated users is a much stronger signal than any single detailed request, however well-argued. One person asking for something tells you what one person wants. Several people asking for roughly the same thing, independently and in their own words, usually tells you about a real gap rather than a personal preference.

Why I Didn't Build It Immediately

Even with a clear, repeated signal, I didn't jump straight into building it. Adding any kind of history or lookback feature touches how data is stored and displayed throughout the whole app, not just one screen — which meant it needed real planning rather than a quick patch. Rushing a structural change to satisfy demand quickly is a good way to end up needing to redo it properly a few months later anyway.

Instead, the next stretch of work went into scoping the feature properly: what the simplest useful version would look like, what could be left out of a first version without disappointing the people who'd asked for it, and how much additional complexity it would add to the parts of the app that were already working well. That scoping work is far less visible than shipping a flashy new feature, but it's the part that determines whether the eventual feature actually holds up.

A General Way to Think About "What's Next"

Stripped of the specifics of this particular app, the approach that emerged looks something like this, and I think it holds up for almost any small project with real users:

• Don't treat every piece of feedback as equally important just because it's real feedback. Look for repetition across different people before treating a request as a priority.
• Separate requests that deepen what the product already does from requests that would turn it into something else entirely.
• Resist the urge to ship a structural change quickly just to be responsive. A properly scoped feature that arrives a bit later beats a rushed one that needs to be redone.
• Remember that saying no to a reasonable-sounding request is sometimes the choice that best serves the people already using and liking what you built.

A Reminder About What This Blog Covers

This blog remains a record of one person's experience building a personal algorithmic trading system and the tools that grew out of it — not investment advice, and not a promise that any of these decisions will play out the same way for someone else's project. Trading and building software both involve real risk and real uncertainty, and the honest account here is meant to be read as exactly that: an account, not a guide to be followed step by step.

That's where things stand a month and a half after launch — a working routine, a clearer sense of who the core users are, and one carefully scoped feature in the pipeline. The next posts will follow how that feature actually comes together, starting from the planning decisions covered here.