Last summer, Lily spent 9 months releasing a single app.
"It's not finished yet," "Let me polish it a bit more," "I can't stop worrying about this UI"—I kept making excuses like these, but I think the real reason was fear. Fear of putting it out into the world. Fear of being seen.
When I finally released it, the user response was honestly underwhelming. But that experience taught me so much. There's plenty of talk about what to do. But today, I want to talk about what not to do—the habits that drained my time and mental energy throughout my journey in personal development.
I was definitely doing this in the beginning.
"It's not ready to show yet," "Let me tidy it up a bit more," I'd think, continuing to build alone. Three months later, when I finally showed it to a friend, they immediately asked, "Do you really need this feature?"
That feature was the one I'd spent the most time on.
I think the problem with perfectionism is that it lets you avoid the fact that you might be pursuing perfection in the wrong direction. Showing it early gets you feedback like "this is off" or "this would be better." Perfectionism activates when you're afraid to receive that feedback.
Now I'm conscious about "shipping at an embarrassingly early stage." Even if it's still rough around the edges, iterating based on reactions is 100 times faster than polishing alone without showing anyone.
I once spent weeks trying to build "something vaguely useful."
When your target user is "someone vaguely busy" or "someone who uses their phone a lot," you're not actually helping anyone. Trying to cater to a vague imagined user causes features to keep piling up, and you lose sight of what the app is supposed to do.
When I decided "I'm building this for this specific person," the confusion finally disappeared.
When I started building something based on a friend's comment—"I'm struggling with this kind of thing"—I could decide on specifications without hesitation. I wasn't afraid to cut features. When you have a reason like "this person doesn't need it," decision-making becomes surprisingly simple.
Building without knowing who it's for is like walking without a map.
When I first started personal development, I was desperate to try new frameworks and tools. Choosing based on the motivation of "let's use that trendy thing" led to sparse documentation and getting stuck when hitting bugs with no information available.
The worst was when I used a beta-version library for the core part of the app. The API changed in a breaking way midway through, and weeks of work went to waste.
In other words, I was getting satisfied with the technology selection itself. There was definitely a part of me that was intoxicated by "myself using interesting technology."
My current standard is "use something boring enough to be mature, with plenty of information available." I explore new technologies as a hobby, but I don't use them in products I want to release. Technology is just a means—a tool for what I want to build.
I've had the experience of starting to "look for similar services" and realizing 4 hours had passed. Multiple times.
Competitive research itself isn't bad. But the more I researched, the more I'd think "it already exists," "they have more features," "their design is completely different," and my motivation to build would drain away.
What's really scary is that research makes your own idea "look faded."
"This idea is already being done by someone"—but thinking about it, that's obvious. The existence of a competing service also means there's demand for that problem. My reason for wanting to build it, my own perspective, my understanding of my users. I found it much more constructive to focus on those things.
Once I decided to "research competitors for only 30 minutes," I was able to move forward.
"This would be convenient too," "Maybe I need that feature," "I should add notifications"—there was a time when I tried to include everything in the first version.
As a result, I couldn't release for months.
The number of features and user satisfaction don't correlate. Rather, the more unused features pile up, the more your truly important features get buried. What users initially want is often just something simple that solves one problem.
Now I ask myself: "If this was the only feature, would there still be people who'd use it?" If the answer is yes, I release in that minimal state first. Features I want to add are considered after release, when they're actually requested.
Cutting features isn't compromise—it's prioritization. Once I realized that, the barrier to release dropped significantly.
There was a time when I pursued design perfection despite not being good at design.
I'd try dozens of color combinations, swap fonts around, and get bothered by a single pixel's misalignment. Before I knew it, I'd spent the whole day on design.
I think the problem was that I was pouring resources into something I couldn't control. Design sense doesn't develop overnight. Yet I was trying to compete on design.
Now I set "simple and clean" as the minimum bar and focus on functionality and copy. I've lost my resistance to using existing UI components as-is. For personal development, design should be "unobtrusive"—that's about right.
Personal development is solitary work. Especially when you hit a wall.
I once spent 5 hours stuck on "why won't this work," nearly giving up. The next day, I sent a message to a friend: "I'm stuck on this kind of problem." They gave me the solution in 10 minutes.
It's not just stuck problems. Just talking about "I'm building this" gets you unexpected feedback. Sometimes people say "I want that." When building itself becomes painful, talking to someone can help you keep going.
I thought "they might not understand," so I stayed quiet, but people are surprisingly interested in listening. Since I started showing up at personal developer communities, the loneliness has eased considerably.
Just talking to someone—that alone can help you keep going.
Looking back, almost everything I'm glad I didn't do was either "trying to make it perfect" or "being too scared to move."
Not making something perfect before moving, but moving while approaching perfection. Once I got into that cycle, personal development finally became fun.
Even now, I sometimes want to include everything, want to polish without showing anyone. When that side of me shows up, I try to notice: "Ah, I'm getting scared again."
If someone reads this article and thinks "that's so relatable," I'd be happy. Let's move forward together, little by little.
Lily (@bokuwalily)— Personal developer. Building iOS apps and web services in tandem with AI.
