Nine Comments from One User: Why "User-Requested Features" Are Harder to Build Than "Your Own Ideas"

On October 3, a user posted a single example in the issue tracker for my project YiziMarkdown: in presentation mode, an overly long inline code line was being truncated. In passing, they also said, "Presentation mode is the most distinctive feature you've built."

I was glad for the recognition, and in last week's v0.3.3, I specifically fixed the bug they mentioned and added the features they'd requested—presentation columns, font size, fill width, and the like.

By October 18, that issue had nine comments: font size, code block font size, PDF export fonts, Word export list markers, vertical alignment, whether presentation layouts could be exported... and tucked in among them was this: "The collapse format toolbar feature re-expands whenever the window size changes, and the title bar can't be maximized by double-clicking—does this count as a bug?"

Honestly, having a user engage with your product so thoughtfully and give you feedback—as a vibe-coding developer, that's a real privilege.

I replied, "Okay, I'll take a look. Sorry, things have been really busy on my end these past few days, haven't had a chance to adjust it yet." That wasn't a complaint—it was just a normal follow-up—but it reminded me of the other half of the cost of an issue: it keeps generating expectations outside your plans.

This version took me two or three days, start to finish. The tiring part wasn't the code.

Why "user-requested features" are harder than "your own ideas"

If it's a feature I want to build myself, the process is simple: think of it, change it, try it out myself, feel good, ship it.

The first move with a user request isn't opening the agent—it's thinking: Is this a shared need others resonate with, or something only this one person will hit? Should I do it? If I do, how far is far enough?

There's an easy misunderstanding here: it's not that "someone thought of a need you didn't, so you happily start building." The real mindset is often cautious, hesitant, sometimes even a little resistant—because you're investing time in something you didn't propose, and taking on long-term maintenance responsibility for it.

And users usually hand you a solution directly: they say they want columns like moonslide, or to export presentations to PPT. What you have to judge is never the solution itself, but the need behind it.

Four ways of handling things in the same week

The first: it looks like a suggestion, but it's actually a bug. "Collapse format toolbar re-expands whenever the window changes," "title bar can't be maximized by double-clicking"—these aren't preferences, they're things I got wrong before. They're bugs. So what I did wasn't "adopt the suggestion" but "do it thoroughly": there are now two collapse mechanisms—auto-collapse on window change doesn't remember state, user-initiated collapse does; double-click-to-maximize on the top bar's empty area and a right-click menu were added too.

The second: personal preference. They said an initial font size of 14 or 16 would be better, and the code block font is too small. That's not something I should decide for them—font size persists once set, so I left the default alone and left the adjustable parts to the user. Defaults are for new users; preferences are for returning ones. The two need to be kept separate.

The third: beyond the product's boundaries, but the need still has to be caught. They asked for "export to PPT," and I declined: this product handles markdown documents, and presentation mode exists so people don't have to touch PPT for informal occasions; per-element adaptation would also be a pain. They clarified they actually wanted "export presentation to PDF," which is worth looking into. As for columns, they wanted a complex markup system, and I gave them ***—no new syntax, inferring layout from native markdown syntax. In an earlier version, someone wanted a tagging system too, and I didn't build that either, because YiziMarkdown is positioned as a document editor, not a knowledge manager.

Declining a request doesn't mean declining the need—there's often a narrower path in between.

The fourth: not deciding yet. For the vertical alignment start height and presentation PDF export, I replied that "it still needs evaluation" and "the boundaries of presentation mode need to be sorted out." It's okay to not decide yet, but you have to explain why clearly.

That same week, they reported a new batch of problems: exported PDF fonts too large, excessive bottom margin on each line in Word, wrong nested unordered list markers, an extra line in code blocks, and "typing an extra space renders two checkboxes." Fix one, and three more pop up beside it—that's the most honest exhaustion of these past few days: it's not that any one thing is hard, it's that the boundaries keep moving.

Then I turned around and asked myself a question

If I review what users propose with "is this a shared need," then by what right do the features I add myself, the rules I set myself, pass?

They're essentially "a user's request" too—it's just that that user happens to be me.

Honestly, they wouldn't pass the same strict review. So I just swapped out the ruler: instead of asking "does everyone want this"—a question you can never prove—I ask three things:

Will it break if I don't do it? (Yes, then it's a bug, and it must be done.) After doing it, will everyone find things a little smoother? (Yes, then it's shared, and worth doing.) Can I clearly say who it serves, where the boundaries are, and who maintains it later? (Yes, then it can be done.)

Measure my own ideas with this ruler: renaming "About" in settings to "Version & Updates" because the name was no longer accurate; adding a "Other Products" tab because it's just a read-only list plus a few official links, with near-zero cost and maintenance—both pass.

Only one didn't pass, and it came precisely from my own need.

The last thing I didn't do

Something I thought about for a long time: adding a "Publish" feature in the editor that sends the current document to my personal site's blog with one click. I spent half a day looking into APIs, platforms, and various standards, and in the end I didn't do it—not because it's technically impossible, but because I couldn't convince myself "it's not just for me."

To make it usable by others, I'd have to integrate a whole bunch of platforms; to serve only myself would mean opening a door in a product meant for others that only opens for me. Who does it serve? Can't say. Boundaries? Can't say. Maintenance? Long-term, it's my own problem. It didn't pass the ruler.

This is my example in this piece of "rejecting myself."

In closing

That user's issue ultimately helped me see something I couldn't see myself: some places are "nice to improve but not essential," and after using them long enough, I stop noticing. What was truly useful in their "does this count as a bug" wasn't the request—it was a mirror.

One line in my reply to them was sincere: "It was your thoughtful suggestions that led me to refine the top bar, format toolbar, and the right-click menus across various functional areas—experiences that were nice to improve but not essential."

This version doesn't have many features, but it involved the most thinking. No one sees the process of thinking things through, but it determines what I cut, what I keep, and whether I can ship the next version with a clear conscience.

Scrutinize user needs, but scrutinize your own even harder—because when it comes to yourself, you can always find a way to be convinced.