I'm writing an essay. For a long time, I've been thinking there's a screen I don't want to open. The comment list from users who canceled their subscriptions. It sits quietly in the corner of the dashboard, yet the numbers alone creep up a little each month. Last month there were 17. I could find out in a second how many of them left text if I opened it. And yet I went months without clicking there. It wasn't so much fear as a state of "I'm not ready to read and be hurt yet." It might be close to that feeling of not wanting to see notifications on your phone, so you leave the screen face-down. What I want to talk about today is the story of finally opening it one night, reading everything, and receiving something unexpected.
As an excuse for not reading the cancellation comments, I had given myself several reasons. "It's biased data where only complainers' voices gather." "I'll get emotional and my judgment will be distorted." "Even if I read it, I can't change anything."
Looking back now, they were all just justifications to protect myself from opening it.
The truth was simple: I didn't want to watch my eyes follow text saying "this wasn't what I expected" or "it was disappointing" about something I'd spent time creating. That's all it was. Even knowing this, it takes time to admit it—and when you're doing solo development, there are surprisingly many things like this.
At the end of July, someone else who was building a subscription app posted something like this on social media: "I transcribed all the cancellation reasons into a spreadsheet and analyzed them. I narrowed down 3 features from that. The next month's update slightly reduced the churn rate."
At first I thought, "That's amazing, how can they do that?" I wondered if they didn't get hurt reading them.
But after a while, I started to see it differently. Maybe that person wasn't thinking about whether it would hurt—maybe they were reading it thinking "there's information here." Maybe they were reading the same text with a completely different framework for receiving it.
"Reading to Get Hurt" vs. "Reading to Learn"
As for whether I could make that distinction, honestly I couldn't at all. Before even opening the comments, I'd decided "there are painful things written here," and I'd stop there. I was drawing conclusions before opening it.
That night, I decided to try something. I would open it with a different purpose in mind: not "receiving feedback" but "looking for hints about what to build next." It sounded a bit silly when I said it out loud, but it worked.
In the first week of August, just after midnight, I finally opened the dashboard.
In the 17 comments, 11 had text. The remaining 6 were just cancellations with nothing written.
I Almost Stopped After the First 3
To be honest, after reading the first 3, I almost closed it. "Didn't understand how to use it." "The UI feels old." "The price was higher than I expected." Each one stung. The phrase "feels old" especially made me unable to look away from the screen for a while. The memory of how much time I'd spent on that design came flooding back.
But I didn't close it. I quietly repeated the words "looking for hints about what to build next" and moved to the next comment.
From the 4th Comment, My Perspective Shifted
The 4th comment said: "I only used it once a week, but the monthly fee was too much." The moment I read it, I understood. It wasn't that they didn't use it—their usage frequency and the pricing didn't match. That was something I could have chosen on my side of the design. A weekly plan was something I'd thought about before but put off because it seemed like a hassle.
The 8th one said: "I liked the features themselves, but there were too many notifications." I'd heard similar feedback through another channel a month ago and had been putting off dealing with it. Regret and the feeling of "this is something I can fix" came almost simultaneously.
After Reading All 11
It took about an hour to read them all. What surprised me when I finished was that among the 11 comments, there wasn't a single one saying "I hated this service."
"It didn't match my usage pattern." "The timing was bad." "A certain feature was missing." Each one was something where if I changed something, the outcome could have been different. I don't think it applies to everyone, but more than half of the comments could be read that way.
The next morning, I transferred the words that came out of the comments into a sticky note tool. With one rule: don't write impressions or interpretations, just "the words themselves."
"A plan for once-a-week users." "Fine-grained notification adjustment settings." "The initial explanation was too short (same point in 3 comments)." "Wanted integration with ○○." ... When I wrote them out, there were 10. Of those, 7 were things I'd been vaguely thinking "I'll do that later" about.
I Flipped the Priority Order
Looking at this memo, I rearranged the next update schedule. I pushed back the original plan of "adding new features" and decided to do "adding notification settings" and "improving onboarding" first instead.
I don't know yet if this is the right call. The people who canceled won't necessarily come back, and there's no guarantee the next cancellations will stop. But at least it's a judgment based on words that someone actually spoke. That's a different kind of basis than "this just feels right somehow." Just that much made me feel a bit more settled as I got started.
It might sound grandiose, but that's what I think now.
I thought about why people who are leaving would bother to leave words behind. Some people probably just want to vent their frustration. But someone who wrote "I would have kept using it if there was this feature" probably wanted to use it just a little longer. Maybe they were trying to pass something on to the next maker as they left.
I'd been leaving those words unread. I think that was wasteful now.
I understand the feeling of not wanting to read because you're afraid of being hurt. I felt that way for a long time. But if you don't read, you end up releasing the next version without knowing what to fix. That has its own kind of fear. It's like running forward without knowing where you're going.
When you're doing solo development, there are many moments when you have to decide "what to build next" by yourself. There's little data to reference, no team to discuss with, and no one to answer the question "is this right?" That kind of loneliness lingers no matter how used to it you get.
In that sense, I think cancellation comments can become a map. Not a complete map, and it takes a little courage to start reading it, but it's still something that draws a line where there was nothing before.
The numbers will probably increase next month. Some of them will have words. Next time, I'm thinking I'll open it a little sooner. Not going to get hurt, but going to receive.
Lily (@bokuwalily) — Solo developer. Building iOS apps and web services in tandem with AI.
🎁 A free bonus for reading all the way through: LINEで「自動化」と送って受け取る（実装テンプレ7本）
Lily (@bokuwalily) — Solo developer / AI adoption and business automation consultant. Building iOS apps and web services in tandem with AI while consulting on AI adoption and automation for companies.
🖥️ Works and articles → bokuwalily.com
🐙 OSS → github.com/bokuwalily
🌍 Latest info and inquiries → X @bokuwalily
