AI translation
"Could you add a small feature for me?" When Lily read that message, she felt, to be honest, a little proud. The fact that the people using it were sending her feedback like this meant that the app had grown. There was definitely someone on the other side of the screen. Just that alone made her happy...
Enjoyed this article?
Use "Request tipping" to ask the author to set up tip receiving.
"Could you add a small feature for me?" When Lily read that message, to be honest, she felt a little proud. The app had grown enough that someone using it was sharing their feedback like this. There was definitely someone on the other side of the screen. That alone made her happy. But at the same time, something was bothering her. The requested feature wasn't technically difficult. She was confident she could implement it in a day or two. Yet her fingers stopped. When she asked herself, "Do I want to add this feature?" the answer didn't come smoothly. This essay is about that moment. The day she made the choice to decline for the first time, the day she discovered feelings about her app that she hadn't even noticed herself. It's not a success story, and I'm not trying to make it sound like a lesson. I'm just writing honestly.
The app Lily develops individually was originally made for herself. It's a simple tool for keeping records, with the concept of "minimal operations, only what's necessary." She thought that limiting features was the app's identity itself, and even after releasing it, she had been careful not to add anything unnecessary.
The message came from a regular user who had sent feedback several times before. The request was: "Could you make it possible to customize the colors of categories?" She could sense that they wanted to make it more their own through using it. It was a request that came from actually using the app, and she was grateful for it.
On the first read, she thought, "Oh, that might be nice." It was a thoughtful request, and implementation wouldn't be that difficult. But on the second read, she felt something that didn't sit right.
She couldn't quite put it into words, but she had a sense that "if color customization gets added to this app, something will change." It was groundless, almost intuitive. The user's request made sense, yet she found herself thinking "I don't want to do this."
That discomfort made her feel a bit guilty. She wondered if it was just the creator being selfish.
Declining wasn't an option she'd considered from the start. She thinks she had a fixed belief that responding to user feedback was the right thing to do. So at first, she just tried to implement it.
She thought about the design, sketched out the screen, mentally assembled how it would work. About an hour into doing this, her hands suddenly stopped.
Before she knew it, she could see in her mind an app that was slightly different from what she'd wanted to create. It wasn't bad. But something felt off. Even though she'd valued "minimal operations, only what's necessary," the settings options were increasing, the choices were multiplying, and the app felt like it was getting a bit heavier.
She stopped the implementation that night. She closed the file and sat blankly for a while. All she felt was that there was something she needed to face properly.
It was the first time she seriously considered declining.
With individual development, unlike products at big companies, you don't have shields like "the specs are this way" or "the policy is this way." Your judgment becomes the app directly. If she declined, it would mean "Lily declined." That scared her a little.
She tried to write a reply, rewriting it many times.
"Thank you for the request. We'll consider it" didn't feel honest, but if she was honest, she might hurt their feelings, so her fingers stopped. She realized that what she feared most was "losing someone who loves this app." Thinking that far, she understood: oh, I really do care about this user. That's why declining was scary. But at the same time, she had a clear sense of the direction she wanted this app to go. Those two things were genuinely in conflict.
The reply she ultimately sent said something like this:
"Thank you so much for the request. To be honest, I'm thinking of not adding this feature to the app this time. The reason is that I want to keep the simplicity of operation as much as possible. I think that's what makes this app unique. I was really happy that you shared your feedback. If there's anything else you're curious about, please let me know."
After sending it, she felt nervous for a while.
The next day, the user replied: "Got it! So that's the concept—I understand. I'll keep using it."
It was surprisingly straightforward. The gap between the weight of guilt she'd been carrying and how lightly the other person took it was almost funny, and she found herself laughing a little.
But at the same time, she felt very relieved. She'd been honest, it had gotten through, and they were still going to use it—all three things came together. After reading the reply, she just sat there for a while.
Since that day, her sense of her app has changed a little.
Before, it felt like "I'm creating the app," but when she made that decision to decline, a new sense emerged: "the app has a direction it wants to go." She can't quite explain it, but it's like the app became something separate from herself.
With individual development, you decide everything yourself. So naturally, the app should be nothing but your own will. But as you keep making it, the app gradually becomes something "a little different from yourself."
Looking back, when she stopped the implementation that night, it feels like the app was saying "this is different," and that's why she stopped. It might sound a bit strange to say it that way, but that's how it felt at the time.
By declining, she was finally able to put into words where her app wanted to go. Thinking about the reasons for declining became an exercise in articulating her concept.
To be honest, if a similar request comes next time, she thinks she'll hesitate again.
Should she protect the concept, or respond to the user's voice? This isn't a problem with a clean answer, and the judgment might be different each time. She thinks that's okay.
After that experience, something changed within her. She realized that "having reasons for what you don't do" is necessary as a creator. Being able to explain to yourself "why I'm not adding this." Without that, the app would sway every time a request came in. She finally understood with real feeling that having a concept necessarily means there are things you don't do.
There's no perfect way to decline, and Lily's approach isn't necessarily the right answer. But she's glad she tried being honest about it.
If there's anyone out there struggling with how to respond to requests the same way, she wanted to convey this: "declining" might not be rejection—it might also be honesty toward your own app. Whether it works out or not, you won't know until the moment comes. Still, Lily doesn't regret what happened that night.
Lily (@bokuwalily) — Individual developer. Making iOS apps and web services in tandem with AI.
「ちょっとした機能を追加してもらえませんか」 そのメッセージを読んだとき、Lilyは正直なところ、少し誇らしい気持ちになりました。使ってくれているひとが、こんなふうに意見を届けてくれるくらいには、アプリが育ったということだから。画面のむこうに、確かに誰かがいた。それだけで、嬉しかった。 でも同時に、何かが引っかかっていました。要望の内容は技術的には難しくない。一日か二日あれば実装できる自信もあります。それなのに、指が止まりました。「この機能、入れたいか?」と自分に問いかけたとき、答えがするっと出てこなかったのです。 このエッセイは、そのときの話です。断るという選択をはじめてとった日、自分でも気づいていなかったアプリへの気持ちに気づいた日について。うまくいった話でもなく、教訓めいた話にするつもりもなく、ただ正直に書きます。
Lilyが個人で開発しているアプリは、もともと自分のために作ったものでした。記録をつけるためのシンプルなツールで、コンセプトは「とにかく少ない操作で、必要なことだけ」。機能を絞ること自体がアプリの個性だと思っていたし、リリースしてからも余計なものを入れないようにしてきました。
メッセージをくれたのは、何度か感想を送ってくれていた常連ユーザーさんでした。要望の内容は、「カテゴリの色をカスタマイズできるようにしてほしい」というものでした。使っていて、もっと自分のものにしたいという気持ちがあるんだなと伝わってきました。ちゃんと使ってくれているから出てくる要望だし、ありがたいと思いました。
最初の一読目は、「あ、いいかもしれない」と思いました。ありがたい要望だし、実装もそう大変じゃない。でも二読目のとき、なんとなく腑に落ちないものを感じました。
うまく言語化できなかったのですが、「このアプリにカラーカスタマイズが入ったら、何かが変わってしまう」という感覚がありました。根拠もなく、直感に近いものでした。ユーザーさんの要望は理にかなっているのに、自分がそれを「したくない」と思っている。
その違和感が、少し後ろめたかったです。作り手のわがままなんじゃないか、と。
断るという選択肢は、最初から頭にありませんでした。ユーザーの声に応えるのが正しい、という思い込みがあったのだと思います。だから最初はとにかく実装しようとしました。
設計を考えて、画面のラフを描いて、どんなふうに動かすか頭のなかで組み立てて。一時間くらいそれをやっていたとき、ふと手が止まりました。
気づいたら画面のなかに、自分が作りたかったものとは少し違うアプリの姿が見えていました。悪くはない。でも、なんか違う。「少ない操作で、必要なことだけ」を大切にしていたのに、設定項目が増えて、選択肢が増えて、アプリが少し重たくなっていく感じがしました。
実装を途中で止めたのは、その晩のことです。ファイルを閉じて、しばらくぼーっとしていました。ちゃんと向き合わないといけない何かがある、という感じだけがありました。
断ること自体を、真剣に考えたのはそのときがはじめてでした。
個人開発って、大きな会社のプロダクトと違って、「仕様はこうだから」「方針がこうだから」という盾がありません。自分の判断がそのままアプリに出る。断るとしたら、「Lilyが断った」ということになる。それが少し怖かったです。
返信を書こうとして、何度も書き直しました。
「ご要望ありがとうございます。検討させていただきます」では正直じゃない気がして、でも正直に言ったら嫌な思いをさせてしまうかもしれない、と思って指が止まりました。
自分がいちばん恐れていたのは、「このアプリを好きでいてくれるひとを失うこと」だったと思います。そこまで考えて、あ、自分はこのユーザーさんのことをちゃんと大事に思っているんだな、とわかりました。だからこそ断るのが怖かった。でもそれと同時に、このアプリが向かいたい方向も、自分のなかにはっきりあった。その二つが、ちゃんとぶつかっていました。
最終的に送った返信は、こんな内容でした。
「ご要望、とてもありがとうございます。正直に伝えると、今回はこのアプリには入れない方向で考えています。理由は、操作のシンプルさをできるだけ保ちたいというコンセプトがあるからです。それがこのアプリの個性だと思っているので。要望を届けてくださったこと、すごく嬉しかったです。もし他に気になることがあれば、またぜひ聞かせてください」
送った後、しばらくドキドキしていました。
翌日、ユーザーさんから返事がきました。「わかりました! そういうコンセプトなんですね、納得しました。これからも使います」というものでした。
拍子抜けするくらい、あっさりしていました。こちらが抱えていた罪悪感の重さと、相手の受け取り方の軽さのギャップが、正直おかしくて少し笑えてきました。
でも同時に、すごく安心もしました。正直に言えた、伝わった、それでも続けてくれる、という三つが揃った感じがして。返事を読んで、しばらくその場に座ったままでいました。
あの日以来、自分のアプリに対する感覚が少し変わりました。
以前は「自分がアプリを作っている」という感じだったのですが、あの断る決断をしたとき、「アプリが向かいたい方向がある」という感覚が生まれました。うまく言えないのですが、アプリが自分とは別の何か、みたいな感じです。
個人開発って、自分がすべてを決めるんですよね。だから当然、アプリは自分の意思そのものなはずです。でも作り続けていると、アプリがだんだん「自分とは少し違うもの」になっていく気がしています。
あの夜、実装を途中でやめたのも、今思えばアプリが「違う」と言ったような気がして止まった、という感じがあります。少し変な言い方かもしれないけれど、そのときはそう感じていました。
断ることで、はじめて自分のアプリがどこに向かいたいかを、ちゃんと言葉にできた気がしました。断る理由を考えることが、コンセプトを言語化する作業になっていました。
正直に言うと、次に同じような要望が来たら、また迷うと思います。
コンセプトを守るべきか、ユーザーの声に応えるべきか。これはきれいに答えが出る問題じゃないし、毎回違う判断になるかもしれない。それでいいと思っています。
あのできごとを経て、自分のなかで少し変わったことがあります。「断る理由を持つこと」が、作り手として必要なことだと気づいたことです。「なぜこれを入れないのか」を自分に説明できること。それができないと、要望が来るたびにアプリがゆらゆらしてしまいます。コンセプトがあるということは、必然的に「しないこと」があるということだと、ようやく実感を持って理解できました。
完璧な断り方なんてないし、Lilyのやり方が正解というわけでもありません。でも、あのとき正直に伝えてみてよかったと思っています。
もし同じように要望への返し方に悩んでいる方がいたら、「断る」という選択肢は、拒絶じゃなくて自分のアプリへの誠実さでもあるかもしれない、ということを伝えたくて書きました。うまくいくかどうかは、そのときにならないとわかりません。それでも、あの夜のことはLilyは後悔していません。
Lily（@bokuwalily）― 個人開発者。AIと二人三脚で、iOSアプリやWebサービスを作っています
