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.
I think building for yourself gives you an advantage because you understand the problem better than anyone else. The hard part comes later when you have to figure out whether other people care about the same problem for the same reasons. I'm finding that to be the biggest challenge with my own project. Thanks for sharing this.
lesson one is the real unlock, build the problem you actually have. the trap comes next on distribution: myself validates the problem but cant be your growth channel. the good news is your one-sentence problem (context switching, losing the small stuff between tabs) is also your best marketing line, go say exactly that where people already complain about it (r/macapps, productivity subs, HN) and the ones who feel it raise their hand. you dont need a big audience, just to be visible to the handful with your exact problem.
Yes, completely agree, and I think building the problem you actually have makes you more intrinsically motivated in a way that's hard to fake. When I've tried to solve problems for other people before, I spent most of my time just trying to understand their workflow and where the friction actually was, which is a much harder starting point. And even with AI able to do a lot now, it still needs a lot of accurate context to work with, the further you are from actually living the problem, the more research and guesswork has to fill that gap instead of just knowing it firsthand.
Context switching is such a real problem in 2026 and I'd love to help more people name it as an actual problem instead of just something everyone quietly deals with. I've been engaging in r/macapps but hadn't thought about the productivity subs specifically, that's a good call, I'll go look there too. Thanks for the reassurance on this.
What's your background in, and what are you currently building?
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.
Your fridge problem is such a good example of the same trap though, it's clearly real and personal, but I'd guess the hard part is that almost everyone has some version of 'stared into the fridge with no idea what to make,' which sounds like an advantage but might actually make it harder to find your exact person, since how strongly someone feels that pain probably ranges from mildly forgetful to actually wasting food and money every week.
What's your current one-sentence version of the problem, and have you found the place where people are already complaining about it out loud?
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.
A lot of people are in the teething phase, dealing with operational problems, working less efficiently than they could, and mostly just trying to adapt and keep up rather than actually rethinking how they work. That's especially true outside the more technical crowd, a lot of people are just trying to keep pace with the tools that already exist. I think the shift toward wanting to babysit less comes later, once the operational chaos settles down enough that trust becomes the real bottleneck instead of raw capability.
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.
Yes, it really is a jump, totally agree. Right now I'm actually starting even closer than that, touching base with my inner circle first, people I know personally who might feel this, before I go wide into public threads. Feels like the more honest first step before reading strangers' pain out loud. I have been dipping into places like Reddit too, mostly to see how people describe the problem in their own words, but the inner circle conversations are where most of my energy is going right now. Really appreciate the offer on the scoring method, I'll hold off on the call for now, but if you've ever written any of that up I'd genuinely love to read it.
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?