AI translation
I'm writing an essay. On the night she released the app, Lily felt a bit strange. There was certainly a sense of accomplishment, but mixed in somewhere was the feeling that "it might already be too late." It was because by the time she released the app, she no longer had the problem that the app was trying to solve. ...
Enjoyed this article?
Use "Request tipping" to ask the author to set up tip receiving.
I'm writing an essay. On the night Lily released an app, she felt a bit strange. There was certainly a sense of accomplishment, but mixed in somewhere was the feeling that "it might already be too late." The problem the app was trying to solve was no longer something she was grappling with at the time of release. The "version of herself from back then" that she had spent nearly a year trying to help no longer existed anywhere. It felt incredibly sad, yet strangely refreshing at the same time. I'm writing this to organize my thoughts from that time. I hope to share, even just a little, the difficulty and richness of this experience with others who have similarly "created something for their past selves."
Lily first came up with the idea for this app about a year ago. At that time, Lily was struggling terribly with task management for personal projects. Every morning she would spend 30 minutes wondering "what should I start with today," and by the time she realized it, she had pushed back the thing she most wanted to do. This pattern continued day after day.
She tried several existing tools, but none of them felt quite right. "Then I'll just make one myself," she thought, and jotted down the idea in a notepad. That note still exists, and looking at it now makes her chest ache a little. It said: "I want a system where I can decide what to do today in 5 minutes or less every morning." The Lily of that time believed that would be enough to satisfy her.
Something strange happened after she started developing. As she was building, Lily's own habits changed.
By thinking through the app's design, she naturally gained more opportunities to put into words "what she was struggling with." While designing the UI, thinking "what state is the user in when they press this button?" became a way of organizing her own problems. Before she knew it, the endless morning spiraling that had troubled her so much had decreased significantly.
That in itself was a good thing. But as the release date drew closer, a vague sense of unease began to emerge.
When Lily saw the finished product, the first thing she felt was "I might not actually need this anymore."
The app had been made carefully. What she had built up bit by bit over a year had taken proper shape. But when she tried to start using it, she realized she no longer needed that workflow. The problem hadn't disappeared—rather, a different approach had taken root in her during the development process.
"Was this even worth it?" she thought for a moment. To be honest, she might have stayed discouraged a bit longer. But the first feedback that arrived a few hours after she pressed publish became the answer to that haze of doubt.
The first comment was very brief: "This is exactly what I'm struggling with. I've been having this problem every morning."
When she read it, there was an indescribable feeling. The "unease" Lily had felt a year ago—someone was feeling it right now. What she had created wasn't "a tool for the current version of herself," but for "someone in the same situation as the version of herself from back then," it was exactly what they needed right now.
After receiving that message, Lily's perspective shifted a little.
Having your problem solved while you're building isn't wasteful at all. Rather, it's evidence that you engaged deeply and continuously with that problem. For a year, she thought about that problem as "her own issue," and that's why she could create something. If she had thought abstractly about "creating for users" from the start, she probably wouldn't have been able to focus on the details the way she did.
"Creating to save your past self" ends up being "saving someone who is currently in the same situation as your past self." That time lag might be one of the quiet strengths of indie development, she felt for the first time that night.
But to be honest, there were failures too.
When writing the introduction after release, Lily was already a bit removed from that problem. So the writing became somewhat detached. She could write explanations like "this is convenient for this type of person" and "this solves this kind of challenge," but the concrete emotions were missing—"the panic from back then," "the melancholy felt first thing in the morning."
After receiving the first feedback, she rewrote the introduction. When she honestly wrote "what I felt a year ago," the response afterward changed dramatically. It was a small realization, but it might have been the biggest lesson for Lily.
Another thing she noticed was that there's a difference in intensity in words written by someone who has "graduated" from a problem.
Words written in the thick of struggling carry desperation. But at the time of release, Lily no longer had that desperation. To compensate, she reread the notes she had taken during development and the memo from when she first wrote down the idea, pulling out "the voice of her past self." Her past self became the best primary source of information.
When she reread that memo, she remembered how much her past self had truly struggled, and her chest tightened a little. She realized: I really was facing this seriously.
When Lily first started indie development, she often saw the advice "think about your users when you create." She doesn't think that's wrong. But for Lily, who struggled with setting up a fictional user persona from the start, it never quite clicked.
"My past self" is the most concrete person in any user persona. She knows the situation she was struggling with, the emotions, what solutions she tried and failed at—all of it. No need to interview, no need to survey. Just honestly ask "what did I need back then?"
After realizing this, Lily stopped thinking "for someone else" first. Instead, she started from the question "what would the Lily from back then have wanted to use?" That way, when she got lost, there was a place to return to.
When you release after a long development period, there's always some kind of gap somewhere. Sometimes the initial design doesn't match the final implementation, sometimes your understanding of the problem has shifted. If you interpret that as "failure," self-denial accumulates with each release.
But looking at it differently, the length of the development period is also "the length of time you spent facing that problem." Lily spent a year thinking about task management from various angles. That accumulation became the resolution of the finished product.
If you feel "I don't need this anymore" at release time, it might mean you've understood the problem sufficiently.
Of course, not everything is like this. But for Lily, this reframing made things much easier.
It's common for problems to be solved as a byproduct of building. While writing code you think about design, while thinking about design you organize the problem structure, and while organizing you see the path to a solution. Indie development might be a kind of "long-term interview" with a problem. The result is that the output (the app) and your own change happen simultaneously—neither is wasteful. Once she could think this way, her approach to creating became a little lighter.
Lily wanted to write this essay to accurately record what she felt that night when she pressed publish while thinking "it might already be too late."
That "slightly strange sense of accomplishment" she felt then, she now thinks, was something precious. It was evidence that she had engaged with something long enough that her problem awareness had shifted. And that record sometimes reaches someone who is right now in the midst of the same problem. The time lag in indie development might not be a failure—it might be how it's designed to work.
If there's someone standing in front of the publish button right now thinking "was this even worth it?", go ahead and press it. Even if your past self is no longer there, someone standing in that same place right now might receive it properly.
Something created for your past self becomes useful for someone today. Lily thinks that's the quietest and most certain meaning of indie development.
Lily (@bokuwalily) — Indie developer. Creating iOS apps and web services in tandem with AI.
エッセイを書きます。 アプリをリリースした夜、Lilyは少し不思議な気持ちになっていました。達成感はたしかにあったのに、どこかに「もう遅いかもしれない」という感覚が混じっていたんです。 そのアプリが解決しようとしていた問題を、リリースした時点の自分はもう抱えていなかったからです。一年近くかけて作ったもので救おうとしていた「あの頃の自分」は、もうどこにもいませんでした。 それがすごく悲しいような、でも不思議と清々しいような気持ちで。この文章は、そのときのことを整理するために書いています。同じように「かつての自分のために作った」経験のある方と、そのしんどさと豊かさを、少しだけ共有できたらと思っています。
Lilyが最初にそのアプリのアイデアを思いついたのは、一年ほど前のことです。当時のLilyは、個人プロジェクトのタスク管理にひどく困っていました。毎朝「今日何から始めるか」で30分悩んで、気づいたら一番やりたいことを後回しにしている、という日が続いていました。
既存のツールをいくつか試してみましたが、どれもしっくりきませんでした。「だったら自分で作ってしまおう」と思ってメモ帳に書き留めたのが始まりです。そのメモは今でも残っていて、見ると少し胸が痛くなります。「毎朝5分以内に今日やることが決まる仕組みがほしい」と書いてありました。あのときのLilyは、それだけで満足できるはずだと信じていたんです。
開発を始めてしばらくすると、不思議なことが起きました。作っているうちに、Lily自身の習慣が変わっていったんです。
アプリの設計を考えることで、「自分が何にぶつかっているのか」を言語化する機会が自然と増えました。UIを設計しながら「このボタンを押すときのユーザーはどんな状態か」を考えることが、そのままLilly自身の問題整理になっていました。気づいたら、あれほど悩んでいた朝のぐるぐるがずいぶん減っていたんです。
それ自体はいいことです。でも、リリースの日が近づくにつれて、なんとなくざわざわした感覚も湧いてきていました。
完成品を見て、Lilyが最初に感じたのは「これ、今の私には要らないかも」でした。
アプリは丁寧に作れていました。一年かけて少しずつ積み上げたものが、ちゃんと形になっていました。でも使い始めようとしたとき、自分がもうそのフローを必要としていないことに気づきました。問題が消えたのではなく、作っている間に別のやり方が自分の中に根付いていたからです。
「これって意味があったのかな」と、一瞬だけ思いました。正直に言うと、もう少し長く落ち込んでいたかもしれません。でも公開ボタンを押してから数時間後に届いた最初のフィードバックが、そのもやもやへの答えになりました。
最初のコメントはとても短いものでした。「これ、まさに今の私の悩みです。毎朝ずっとこれで困ってました」。
読んだ瞬間、なんとも言えない感覚がありました。Lilyが一年前に感じていた「あのざわざわ」を、今まさに誰かが感じている。自分が作ったのは「今の自分のためのツール」ではなかったけれど、「かつての自分と同じ状態の誰か」にとっては、まさに今必要なものだったんです。
そのメッセージをもらって、Lilyは少し見方が変わりました。
作っている間に自分の問題が解決されてしまうのは、決して無駄なことじゃない。むしろ、それだけ深くその問題に向き合い続けたということの証拠でもあります。一年間、その問題を「自分ごと」として考え続けたから、作れたものがある。もし最初から「ユーザーのために」と抽象的に考えていたら、あそこまで細部にこだわれなかったと思います。
「かつての自分を救うために作る」というのは、結果として「かつての自分と同じ状況にいる誰か」を救うことになる。そのタイムラグが、個人開発のひとつの静かな強みかもしれないと、はじめて感じた夜でした。
ただ、正直に書くと、失敗もありました。
リリース後の紹介文を書くとき、Lilyはもうその問題から少し遠い場所にいました。だから文章がどこか他人事になってしまったんです。「こういう人に便利です」「こんな課題を解決します」という説明は書けても、「あのときの焦り」「朝起きて最初に感じる憂鬱」のような具体的な感情が抜けていました。
最初のフィードバックをもらってから、紹介文を書き直しました。「一年前の自分が感じていたこと」を素直に書いたら、その後の反応がずっと変わりました。小さな気づきでしたが、Lilyにとってはこれが一番大きな学びだったかもしれません。
もう一つ気づいたのは、問題を「卒業してしまった人」が書く言葉には、どこかに熱量の差があるということです。
困っているど真ん中で書く言葉には、必死さがにじみます。でもリリースのタイミングでは、Lilyはもうその必死さがなかった。それを補うために、開発中につけていたメモや、最初にアイデアを書いたときのメモを読み返して、「あのときの自分の声」を引っ張ってきました。過去の自分が最大の一次情報提供者でした。
あのメモを読み直したとき、一年前の自分が本当に困っていたことを思い出して、少し胸がつかえました。ちゃんと向き合っていたんだな、と思ったんです。
個人開発を始めたばかりの頃、Lilyは「ユーザーのことを考えて作れ」というアドバイスをよく目にしました。それは間違いではないと思います。でも、最初から架空のユーザー像を設定するのが苦手なLilyには、なかなかピンときませんでした。
「かつての自分」は、ユーザー像の中でいちばん具体的な一人です。困っていた状況も、感情も、どんな解決策を試して失敗したかも、全部知っています。インタビューしなくていい、アンケートをとらなくていい。ただ正直に「あのときの自分に何が必要だったか」を問えばいい。
それに気づいてから、Lilyは最初に「誰かのために」と考えることをやめました。代わりに「あのときのLilyが使いたかったものを作る」という問いから始めるようにしました。そのほうが、迷ったときに立ち返れる場所がある気がしています。
長い開発期間を経てリリースするとき、必ずどこかにズレが生まれます。最初の設計と今の実装がずれていることもあれば、自分の課題認識が変わっていることもある。それを「失敗」と捉えてしまうと、リリースのたびに自己否定が積み重なっていきます。
でも別の見方をすると、開発期間の長さは「その問題と向き合っていた時間の長さ」でもあります。Lilyは一年間、タスク管理という問題をいろんな角度から考え続けました。その積み重ねが、完成品の解像度になっています。
リリース時に「もう自分には要らない」と感じるとしたら、それはその問題を十分に理解したということかもしれません。
もちろん、すべてがそうとは言えません。でもLilyにとっては、この読み替えがずいぶん楽にしてくれました。
作りながら問題が解決するのは、作業の副産物としてよく起きることです。コードを書きながら設計を考え、設計を考えながら問題の構造を整理し、整理しているうちに解決の糸口が見える。個人開発は、ある意味で問題への「長期インタビュー」のようなものかもしれません。その結果として、アウトプット（アプリ）と自分の変化が同時に起きているだけで、どちらかが無駄というわけじゃない。そう思えるようになってから、作ることへの向き合い方がすこし軽くなりました。
Lilyがこの文章を書こうと思ったのは、「もう手遅れかも」と思いながら公開ボタンを押した夜のことを、正確に記録しておきたかったからです。
あのとき感じた「ちょっと変な達成感」は、今思うと大切なものでした。自分の問題意識が変化するほど長く、何かに向き合ったという証拠だったからです。そしてその記録が、今まさに同じ問題の中にいる誰かに届くことがある。個人開発のタイムラグは、失敗じゃなくて、そういう仕組みなのかもしれません。
もし今、「これって意味あったのかな」と思いながら公開ボタンの前に立っている方がいたら、押してみてください。かつての自分は、もうそこにいなくても、同じ場所で立ち止まっている誰かが、ちゃんと受け取ってくれることがあります。
過去の自分のために作ったものが、今の誰かのためになる。Lilyはそれが、個人開発のいちばん静かで確かな意味だと思っています。
Lily（@bokuwalily）― 個人開発者。AIと二人三脚で、iOSアプリやWebサービスを作っています
