I built for one user. Myself.
I'm not a developer. I see the interface before I see the code. That's exactly how I ended up building a Mac app.
Here are my three lessons:
Lesson one: build the thing you actually have, not the thing you think people want. I spent a while chasing ideas that sounded impressive, built for a "user" I'd invented in my head. Nothing stuck until I stopped designing for a hypothetical person and built the one problem that was actually mine.
Lesson two: if you can't explain the problem simply, you don't understand it yet. My problem was context switching, losing the small stuff, a color, a link, a file, a snippet, a half finished thought, every time I moved between tabs and tools. Once I could say that in one sentence, the product designed itself: a small shelf that holds what you're still using, pinned at the edge of your screen until you need it again.
Lesson three, and the one that actually convinced me this was real: I started using it before it was finished. Not testing it, using it. Every time I reached for it without thinking, that told me more than any amount of planning could. The best use case I found for it was building it.
I called it Tansei, a Japanese word (丹精 / 丹誠) for sincerity and the discipline of doing small things well, again and again. It's designed in the spirit of Mac itself: nothing shouting for attention, nothing there by accident, doing its job and getting out of your way.
Launching soon: https://tansei.io.
Sign up for the waitlist and I'll let you know the moment it's live. When it launches there's a 3 day free trial so you can actually test it out, then it's a one time cost. If you try it and decide it's not for you, even after paying, I'd genuinely love to hear why. That feedback is worth more to me than any sale.
Would love to hear from anyone else building solo, especially the moment you knew your own idea was real.
This line really stood out: “build the thing you actually have, not the thing you think people want.”
I’m learning this the hard way with my own app. I built something around a problem I personally have — opening the fridge, seeing food, and still not knowing what to cook — but I’m realizing that building for your own pain is only step one. The harder part is finding the exact people who feel that same pain strongly enough to try it.
Your lesson about explaining the problem simply is probably the biggest one. If the problem needs five sentences, the product is probably not positioned clearly enough yet.
Really liked this post. It feels more honest than the usual “I launched and everything worked” story.
You described an operational problem, but I'd also ask whether customers see it that way. They may not be buying automation—they may be buying confidence that their business keeps running even when they're not watching every connection.
Building for yourself is the cleanest validation — the jump is usually finding the next 10 people with the same pain in public.
Are you already looking for them in communities (Reddit etc.), or still one-user mode?
If you're hunting, I can show a quick way I score fresh pain threads — 10-min call, no pitch deck.
the reaching-for-it-without-thinking test is the most honest signal there is, but it only measures n=1. i'm building a mac tool for basically the same problem (the small stuff that falls out of your head when you move between tools) and the thing that bit me: the pull you feel is real, but the decisions that feel obviously-right are usually the most personal and least transferable. the underlying pain was universal for the next person, the exact shape of my version wasn't. so trust the instinct, just hold the specific UI choices loosely once a second user shows up.
That's the trap I'm watching for right now. Every UI call in Tansei so far has been validated against exactly one nervous system — mine — so 'obviously right' and 'right for me' are still indistinguishable. What was the first thing that turned out to be personal-not-universal for you once someone else started using it?
for me it was how proactive it should be. i'd tuned the surfacing to my own tolerance, which turns out to be really high (i want the thing pinging me the second it notices something). the first person who wasn't me found that exact cadence nagging, not helpful. wanting the small stuff back was universal, the right dose of interruption wasn't even close. what fixed it wasn't a better default, it was making the dose the first thing they set, before they ever see my opinion baked in. so less "what's the right frequency" and more "whose nervous system is this frequency even for."
Lesson three resonates a lot. The moment you catch yourself using your own tool without thinking about it — that is the signal that's hard to fake. I had the same experience with ReThreads. I built it to solve my own reply workflow on Threads, and the first time I reached for it instinctively I knew it was real. External validation came much later.
That's such a good way to put it, external validation came later. I think that's the part nobody warns you about. You can be convinced an idea is smart for months, but the only proof that actually counts is whether you keep reaching for it yourself without being asked to.
Curious what it was like moving from "I use this" to "other people should use this" with ReThreads. Did that feel sudden, or more like something you only noticed looking back?