The hardest part of building isn’t coding — it’s deciding what to build next
Hi everyone đź‘‹
I recently shared a post about building my AI career tool, and someone reached out with an interesting observation:
“You’ve got the skills to build it, but managing what to build next and staying focused when priorities shift — that’s the overwhelming part.”
That really stuck with me.
Because honestly, coding hasn’t been the hardest part of building my product.
It’s things like:
deciding which feature actually matters right now
fixing bugs vs adding new features
improving UX vs building something new
staying focused when there are too many ideas
As a solo builder, you’re constantly switching roles — builder, designer, product manager, marketer — and it’s easy to feel like you’re doing everything, but not always the right thing.
Right now with my product (an AI career assistant), I’m trying to shift from:
“build more features” → “make what exists actually useful and usable.”
Curious how others handle this:
👉 How do you decide what to build next when everything feels important?
Transitioning from expansion to refinement is a critical refactor that prevents your product from becoming a museum of half-baked features. You can find focus by pausing new development until you reach a specific customer milestone or by logging decisions to track what actually drives value.
What is the single most common task your users are currently struggling to complete within your tool?
I can already see how easy it is to fall into that.
Right now, the biggest struggle I’m noticing is users not immediately starting the interview. They explore a bit, but don’t always take that first action.
So it’s less about missing features, and more about clarity:
👉 what to do first
👉 how quickly they can get value
I’m now focusing on simplifying that entry point so users can go from landing → starting an interview without thinking too much.
Focusing on that "first action" friction is the smartest move you can make. If a user stalls before they even start their first interview, they never get to see the "magic" of what you have built. Getting a user from the landing page to their first win in seconds is much more valuable than adding ten new features they might never find.
This focus on real user needs is why I am building Bunzee.ai. We analyze real human feedback from places like Reddit and App Stores to help founders find these exact bottlenecks before they even start coding. I want to help builders focus on what actually matters to the user right now, instead of guessing.
Since you are currently working on simplifying your user's journey, I would love to get your thoughts on our approach. Would you be open to taking a quick look at Bunzee and sharing your feedback?
In my opinion if you're not sure what you need to build next, you miss data
Could be for example: how your users would benefit a new feature? Does the bug prevents your users from using your product properly?
When choosing to spend time on one new idea or the other: how much traffic both ideas currently have on google trends?
That’s a really good point — I think I’ve been relying more on intuition than actual data so far.
Especially in the early stage, it’s tricky because the user base is still small, so sometimes it feels like I’m making decisions with incomplete signals.
But what you said about bugs vs features makes a lot of sense. If something is blocking users from actually using the product, that should clearly come first.
I haven’t explored things like Google Trends yet for feature decisions — that’s interesting. Right now I’m trying to get more direct feedback from users to understand what actually helps them in their job search.
The shift from "build more features" to "make what exists actually usable" is the one I keep relearning. What worked for me (about to launch a personal finance app, solo) was forcing every new feature idea to answer one question: does a real user lose value today without this? If the honest answer is no, it goes into a parked list and I do not look at it for two weeks. Most of them don't survive the wait. The bigger unlock was picking one user, ideally a friend, and watching them try the existing thing on a call. Half the "features" I thought I needed were actually unfixed UX problems in stuff I'd already built.
This is honestly a great framework.
That question — “does a real user lose value today without this?” — really simplifies decision-making. I can already think of a few features I’ve been considering that probably wouldn’t pass that test.
Also completely agree on watching real users. I’ve seen something similar already — users don’t struggle because a feature is missing, but because what’s already there isn’t clear or easy to use.
I like the idea of “letting features sit for two weeks” — that’s a good way to filter out noise.
I think I’m currently at that exact shift you mentioned: moving from building more to making what exists actually work better.