AI translation
Last summer, I postponed the release date of a certain app three times. The reason was the same each time: "I want to add just a little more functionality." Those "little bits" accumulated, and before I knew it, half a year had passed. At that time, deep in my heart, I was thinking, "The app is becoming half-baked because of the constraints." Time was running out...
Enjoyed this article?
Support Lily
Last summer, I postponed the release date of an app three times. The reason was the same each time: "I want to add just a little more functionality." Those "little bits" accumulated, and before I knew it, half a year had passed. At that time, deep in my heart, I thought: "The app is half-baked because of constraints." Not enough time. Not enough money. Not enough technical skill. I blamed everything, yet tried to overcome everything, and as a result, I stood still with everything remaining half-finished. Now I think a little differently. Constraints weren't the enemy of my app. Rather, I even think that without them, I never would have arrived at its current form. This time, I'd like to write about that.
When I started individual development, I had a kind of omnipotence. I could decide everything by myself. The design, the features, the release timing. I didn't need team consensus. I thought it was the best. But when I actually started working, that "everything" became heavy. Just as I was about to decide on screen design, I'd worry about feature architecture. While designing features, the very concept would start to waver. Having only one person making decisions meant having only one person who was confused.
When I made my first app, the "things I wanted to do" list I made had 38 items. User management, notifications, social login, dark mode, multi-language support... I believed all of it was for future users. But what I actually managed to release was less than half of that.
When talking about time, money, and technical skill, I saw them for a long time as "things I lacked." If I could develop full-time instead of as a side job. If I had a budget for outsourcing. If I had mastered the technologies I wasn't using well. But the "ifs" don't end. I have a day job and need sleep. Money is limited. There isn't enough time to learn unfamiliar technologies before release. That was reality.
One time, working past 1 AM, my motivation suddenly cut out. Looking at the half-finished screen, I thought: "Do I really need all of this?"
The next morning, I looked at the list again with a clear head. Of the 38 items, when I filtered by "Is this something I actually want to use first?" only 7 remained. The rest were imagined needs—"it might be convenient," "someone might use it."
It was scary to cut things. I had the anxiety: "If I remove this, people might not use it." But I didn't have time. It was technically difficult. So I had to cut.
That "had to" was the turning point.
When I narrowed it down to 7, the app's outline suddenly became clear. "What is this app for?" I could finally articulate it to myself.
The tagline that had been vague until then could finally be written in a single line at this stage. By deleting the feature list, the concept remained.
One of the apps I made, I tried to add real-time notifications. But at that time, the implementation was too difficult for me. The more I researched, the deeper I sank. Time was limited. As a result, I decided: "Notifications don't need to be real-time."
But later, I received this feedback from a user: "I like that notifications don't come too often. I like being able to check when I want to."
What I couldn't do technically had, as a result, created a "quiet app" character. Unintentionally, it had become a differentiator.
When I couldn't spend money on design, what I relied on was "making it simple." Reducing decoration lowered implementation costs. Fewer operation steps meant screens that were understandable without explanation.
Saying "I made it simple because I had no money" might sound like compromise. But looking back later, that simplicity became the app's strength. The whitespace that was removed was a far more honest expression than the decoration I wanted to add.
Accepting constraints is different from giving up. But for a while, I couldn't distinguish between them.
I was afraid to say "I can't." When doing individual development, you see amazing things around you. Released in a short time, beautiful screens, abundant features. The feeling that "I need to reach that level too" gradually became pressure.
But at some point I realized: most of the works I envied, while visually impressive, weren't what I wanted to make when I actually used them. And what I wanted to make could only be born within my constraints.
"Accepting" constraints meant "doing my best within that range." It's nothing like surrender. Rather, it was deciding where to fight correctly.
Now, when I start making a new app, I make a "don't do" list first. Before writing out what I want to do, I decide "what I absolutely won't do in this scope."
This works surprisingly well. When "what not to do" is decided, confusion decreases. When I want to add a feature, I can judge: "This isn't on the list, so next time." The cost of decision-making goes down.
I have a favorite way of thinking. Seeing constraints not as "things I lack" but as "the rules of this game."
Games with time limits can be more exciting. With fewer available parts, ingenuity is born. Similarly, "we can't do ○○ this time" as a rule creates the thought: "So what do we do?" The accumulation of those "what do we do?" moments is one of the fun parts of individual development, I think now.
While writing this essay, I was reflecting on those times. That moment at 1 AM, the morning after I deleted the list, when I read the message "I like that notifications don't come too often."
Each one was painful, anxious, or a little frustrating at the time. But now, I'm grateful for all of it.
Constraints didn't just restrict what I made. They made my reason for making it much clearer.
When you continue individual development, there are nights when you think "why am I doing this?" I have them. At times like that, the experience of "accepting what I can't do made things better instead" becomes a small fuel.
It doesn't have to be perfect. I don't have to do everything. Making things properly within the range of what I can do now. That might be the way to keep making things for a long time.
Lily（@bokuwalily）― Individual developer. Making iOS apps and web services in tandem with AI
🎁 A Free Bonus for Reading to the End
LINEで「自動化」と送って受け取る（実装テンプレ7本）
Lily（@bokuwalily）― After leading a marketing organization of 50 people as CMO, I now make iOS apps and web services individually. I consult on customer acquisition, user flow design, and AI implementation and business automation.
🖥️ Works and articles → bokuwalily.com
🐙 OSS → github.com/bokuwalily
🌍 Latest info and inquiries → X @bokuwalily
去年の夏、わたしはあるアプリのリリース日を3回延期しました。理由は毎回同じで、「もう少し機能を足したい」でした。その「もう少し」が積み重なって、気づけば半年が過ぎていました。 そのとき心の奥で思っていたのは、「制約のせいでアプリが中途半端になっている」ということでした。時間が足りない。お金が足りない。技術が足りない。全部のせいにしながら、でも全部を克服しようとして、結果としてどれも中途半端なまま立ち止まっていました。 いまは少し違う考え方をしています。制約は、わたしのアプリの敵じゃなかった。むしろ、それがなかったら今の形には辿り着けなかった、とすら思っています。今回は、その話を書かせてください。
個人開発を始めたころ、わたしには一種の万能感がありました。自分一人で全部決められる。デザインも、機能も、リリースのタイミングも。チームの合意なんて必要ない。最高じゃないか、と思っていました。
でも実際に手を動かしてみると、その「全部」が重くなっていきました。画面のデザインを決めかけたら、機能の設計が気になる。機能の設計をしていたら、そもそものコンセプトが揺らいでくる。決める人間が一人しかいないということは、迷う人間も一人しかいないということでした。
最初のアプリを作ったとき、わたしがリストアップした「やりたいこと」は38項目ありました。ユーザー管理、通知機能、ソーシャルログイン、ダークモード、多言語対応……。全部、いつか使う人のためだと信じていました。でも実際にリリースできたのは、その半分以下でした。
時間とお金と技術の話をするとき、わたしは長い間それを「足りないもの」として見ていました。もし副業でなくフルタイムで開発できたら。もし外注できるだけの予算があったら。もし使いこなせていない技術を習得できていたら。
でも「もし」は続きません。わたしには本業があり、睡眠もいります。お金は限られています。知らない技術を習得する時間も、リリースまでに間に合わせるには足りない。それが現実でした。
あるとき、深夜1時すぎに作業していて、突然やる気が切れました。作りかけの画面を見ながら、「これ、本当に全部いるんだろうか」と思ったのです。
翌朝、冷静になってリストを見直しました。38項目のうち、「これ、自分が一番最初に使いたいか？」という軸で絞ると、残るのは7つでした。ほかは「あったら便利かもしれない」「使う人がいるかもしれない」という想像上のニーズでした。
削るのは怖かったです。「これを外したら、使ってもらえないかもしれない」という不安がありました。でも、わたしには時間がなかった。技術的にも難しかった。だから削るしかなかった。
その「しかなかった」が、転機でした。
7つに絞ったとき、アプリの輪郭が急に鮮明になりました。「このアプリは、何をするためのものか」が、自分の中でようやく言語化できたのです。
それまではぼんやりしていたキャッチコピーも、この段階で初めて一行で書けました。機能のリストを削ることで、コンセプトが残ったのです。
わたしが作ったアプリのひとつに、リアルタイム通知を入れようとしたものがあります。でも当時のわたしには、その実装が難しすぎました。調べれば調べるほど深みにはまる。時間も限られている。結果として、「通知は非リアルタイムでいい」という決断をしました。
ところが後から、ユーザーからこんな声をもらいました。「通知が来すぎないのがいい。見たいときに見に行ける感じが好き」と。
わたしが技術的にできなかったことが、結果として「静かなアプリ」というキャラクターを生んでいました。意図せずして、差別化になっていたのです。
デザインにお金をかけられないとき、わたしが頼ったのは「シンプルにする」という方法でした。装飾を減らすと、実装のコストも下がる。操作の手順が減ると、説明しなくてもわかる画面になる。
「お金がないからシンプルにした」と言うと、妥協のように聞こえるかもしれません。でも、後から見返すと、そのシンプルさがアプリの長所になっていました。追加したかった装飾より、削られた余白のほうが、ずっと正直な表現になっていました。
制約を受け入れることは、諦めとは違います。でも、わたしはしばらくそれを区別できていませんでした。
「できない」と言うのが怖かったのです。個人開発をしていると、周りのすごいものを見てしまいます。短期間でリリースして、きれいな画面で、機能も豊富で。「自分も同じくらいにならないといけない」という感覚が、じわじわとプレッシャーになっていました。
でもあるとき気がつきました。わたしが羨ましいと思っていた作品の多くは、見た目はすごくても、使ってみると自分が作りたいものとは違う。そして、わたしが作りたいものは、わたしの制約の中でしか生まれない、とも。
制約を「受け入れる」というのは、「その範囲で最善を尽くす」ということでした。降参とは全然違います。むしろ、戦う場所を正しく決めることでした。
今は、新しいアプリを作り始めるとき、最初に「やらないことリスト」を作るようにしています。やりたいことを書き出す前に、「今回の範囲では絶対にやらないこと」を決めます。
これが思いのほか効きます。「やらないことが決まっている」と、迷いが減ります。機能を追加したくなったとき、「これはリストに入っていないから次の機会に」と判断できる。意思決定のコストが下がるのです。
お気に入りの考え方があります。制約を「足りないもの」ではなく「このゲームのルール」として見る、というものです。
制限時間があるゲームのほうが、燃えることがあります。使えるパーツが少ないほど、工夫が生まれることがあります。それと同じで、「○○は今回できない」というルールは、「じゃあどうする？」という思考を生みます。その「どうする？」の積み重ねが、個人開発の面白さのひとつだと、今は思っています。
このエッセイを書きながら、わたしは当時のことを振り返っていました。深夜1時のあの瞬間、リストを削った翌朝、「通知が来すぎないのがいい」というメッセージを読んだとき。
どれも、当時は苦しかったり、不安だったり、ちょっとだけ悔しかったりしました。でも今は、そのどれもが「あってよかった」と思えます。
制約は、作るものを縛るだけじゃなかった。作る理由を、もっとクリアにしてくれていました。
個人開発を続けていると、「なんでこんなことしてるんだろう」と思う夜があります。わたしはあります。そういうとき、「できないことを受け入れたら、逆によくなった」という経験が、小さい燃料になっています。
完璧じゃなくていい。全部できなくていい。今のわたしにできる範囲で、ちゃんと作る。それが、長く作り続けるためのやり方なのかもしれません。
Lily（@bokuwalily）― 個人開発者。AIと二人三脚で、iOSアプリやWebサービスを作っています
🎁 最後まで読んでくれたあなたへ、無料の特典があります
LINEで「自動化」と送って受け取る（実装テンプレ7本）
Lily（@bokuwalily）― マーケ組織50名規模を統括するCMOを経て、いまは個人でiOSアプリやWebサービスを作っています。集客・導線設計と、AI導入・業務自動化の相談を受けています
🖥️ 制作物・記事 → bokuwalily.com
🐙 OSS → github.com/bokuwalily
🌍 最新情報・お問い合わせ → X @bokuwalily
