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.
Feels like this kind of personal build often turns into the most interesting niche tools, would love to see what you discover as more people start using it.
How do you balance the joy of building something that perfectly fits your own brain with the pressure to turn it into something more market-friendly?
And also, did you have any challenges once publishing app to marketplaces?
I built for the pickiest user I know, myself . That actually removes the pressure rather than adding it, if nobody else likes it, I still end up with a tool that works exactly the way my brain does, so there's no real downside. That's part of why there's a free trial instead of forcing a decision upfront. If it genuinely meets a need for you, pay for it. If it doesn't, no harm done. No subscription either, you know how many subscriptions people are juggling now, it's exhausting, and I didn't want to add to that pile.
I've also tried to keep feedback genuinely open, there's a way to send it straight from the app, not buried behind a support form somewhere.
On marketplaces, I haven't gone that route yet. I wanted to start direct, with real people actually using it, before handing distribution over to an app store review process. Once it has some real footing I might look at it, but for now it's slow and steady, simple steps on distribution too.
Great, feels like a very healthy way to build
That's so nice and inspiring man
Thank you so much! Are you working on a project yourself?
this really landed. context switching is the tax nobody puts on the invoice, but it's the thing that quietly eats the whole day.
the "best use case was building it" line is so true. the tools i actually keep using are always the ones i made for a problem i was already living, never the clever idea i talked myself into.
and i love that it just gets out of the way. half the stuff i drop is the tools that want attention. curious, did the shape of it change a lot once you started using it every day, or was the first version basically right?
Honestly, the first version was pretty close, mostly because I always start from wireframes before touching anything else. That's the designer in me, I can't build off a vague feeling, I need to see the actual shape of it first.
The thing I noticed working with AI on this is it's great at testing and iterating a design you already have, but it can't hand you a better abstract design if you can't visualize it yourself first. If you skip the wireframe and just describe something in words, you're going in blind, and AI with that little context usually doesn't do a great job either. It's a strange loop honestly, no clean answer for it, but starting from a wireframe every time is what's worked for me.
If you're not a designer yourself, I'd still recommend Figma over skipping straight to prompting. Even a rough wireframe gives the AI something real to react to instead of guessing at what "better" means.
Lesson one hit different for me. I've had an idea for an app I genuinely need myself — nothing fancy, just something built around how I actually cook, not how I think a "user" would want it structured. I haven't started building it yet, mostly because I'm currently helping my family market their apps and haven't given myself permission to prioritize my own idea.
Reading "the best use case I found for it was building it" is a good nudge. Congrats on getting Tansei this close to launch.
Just start small enough that it doesn't feel like it's competing with the thing you're already doing for your family. Even an hour a week on the smallest possible version, one screen, one recipe, one real annoyance solved, is usually enough to find out if the idea holds up before you've spent real time on it. That's basically how Tansei started too. A tiny fix for one thing I kept losing, not a plan.
Good luck!
"One screen, one recipe, one real annoyance solved" — I'm saving this. It reframes the whole thing from a project I need permission to start into something I could just... do this weekend. Thank you, genuinely.
Interesting — so for you it's the UAT + integration loop that eats time. For teams handling expense/vendor approvals, I've heard the context gap is the killer (approver doesn't see competing quotes, etc.). Different worlds, same friction. Thanks for the insight.
What part of your approval process takes the most time? Trying to understand if this is a universal pain.
Good question: “approval” can mean a few different things, and each one burns time differently.
For me it wasn’t one bottleneck so much as a chain:
AI / agent loops: I treat every build as provisional. Ask it to validate, retest, catch what it just broke. That loop is fast per pass, but it adds up when you’re shipping a real product, not a demo.
Human UAT: especially UI/UX. This is the approval that actually matters. Screenshots and “looks fine” from an agent aren’t the same as a person using it. That’s where taste and trust get decided.
Integrations + the build: Quiet plumbing. When it’s solid you barely notice it; when something leaks, everything stops.
So if I had to name what feels longest: not any single checkbox, but keeping that whole system watertight. One weak joint and you’re back in the loop.
I'm not a developer either — I'm actually a chef, and I built my first product (EzWrite) the same way you're describing: for myself first. I kept rewriting messages five or six times because I never trusted my own tone in writing, so I built something that gave me a few versions to choose from.
The moment it felt real: I caught myself using the built version instead of just testing it, exactly like you said. Once I stopped opening a blank message box and started opening my own tool instead, that was the signal.
Also relate to lesson two — I couldn't explain what I was building clearly until I stopped trying to solve "communication" in general and focused on the one moment I actually struggled with: not knowing how to say something difficult. Good luck with Tansei, the shelf-at-the-edge-of-the-screen concept is such a clean way to describe the problem.
A chef (wow)! A great example that you don't need to be a developer to build something meaningful.
It's a good reminder that clarity comes from narrowing the problem, not broadening the solution.
Now that you've found that core moment for EzWrite, have you discovered other use cases that users keep asking for? Or are you staying disciplined and doubling down on that one problem?
Thanks again for taking the time to share this, and wishing you all the best with EzWrite.
Thanks, that means a lot! To answer your question: I'm staying disciplined on the core — it's still "turn a rough message into something polished," nothing broader than that. What keeps evolving is the quality of that one thing. Most of the feedback I get is about the tone and recipient prompts — making sure a message actually sounds human for the context (formal boss vs. casual coworker vs. a different language entirely), not like generic AI output. So it's less "let's add new features" and more a constant kaizen-style refinement of the one feature that matters. Feels like the right trade-off so far.
That trade-off makes a lot of sense. Guarding the one job and making the voice actually land for this boss, that coworker, another language, is harder than shipping a pile of half-features. People can smell generic AI pretty fast (heard of AI slop?); they want something that still sounds like a human wrote it.
Given how good models are at the coding side now: what’s one transferable skill from being a chef that you actually used while building?
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.
Talking to people who don't think like you has been the most valuable part of validating my own product.
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?
That’s a really good point. My current one-sentence version is:
“MealRadar helps people decide what to cook tonight from the groceries they already have, before they waste food or order takeout again.”
But I think you’re right that this may still be too broad. The stronger pain might not be “I don’t know what to cook,” but “I keep buying groceries and still end up ordering food because deciding feels annoying.”
I haven’t found the perfect place yet where people complain about it out loud. My guesses are:
Do you think the sharper wedge is:
or
I’m trying to narrow it instead of pitching it as a generic AI cooking app.
My vote's on 3, deciding faster, but sharpened with a bit of 4 mixed in. The wedge isn't "what should I cook" in the abstract, it's "I already have food in the house and I still ordered takeout because deciding felt like work." That's the exact moment you described yourself, and it's more specific and more frequent than "save money" or "reduce waste," which are outcomes people care about but rarely complain about in the moment.
Nobody vents in real time about food waste, they vent about it after they've already thrown something out. But "I have groceries and still ordered Uber Eats" is a complaint people make same day, annoyed at themselves.
For finding where people say this out loud, I'd search for the actual phrases rather than the category. Something like "ordered doordash again," "wasted groceries again," or "too tired to decide what to eat" will surface the raw language people actually use, which is usually sharper than what shows up in a meal prep or food waste group, since those groups already frame the problem as solved by planning. Budgeting and frugal living subs are probably closer to the real vent than cooking subs, since the guilt there is financial, not culinary. r/EatCheapAndHealthy and general personal finance subs might be worth a look too.
I'd chase the exact words people complain with before locking the positioning. The wedge usually reveals itself in how people phrase the annoyance, not in which category you guess it belongs to.
This is extremely helpful — especially the point that people don’t complain about “food waste” in the moment, they complain after the money/food is already gone.
I think you nailed the sharper version:
“I already have food in the house and still ordered takeout because deciding felt like work.”
That feels much more real than “AI meal planning” or even “reduce food waste.” It’s the exact guilt/friction moment.
I’m going to search using the raw phrases you suggested — “ordered DoorDash again,” “too tired to decide what to eat,” “wasted groceries again,” etc. That makes a lot more sense than only looking in cooking groups, because those people may already be planners.
If you’re open to it, could you do me one huge favor and try the app once? Not for a review — just to see whether the first-use experience matches this wedge or feels too generic.
App Store link: [https://apps.apple.com/us/app/mealradar/id6782612975]
The best test would be:
Your feedback here was already sharper than most of what I’ve gotten including all the AI ideas, so I’d genuinely value your take.
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.
That's a really interesting way to think about it.
Reading your reply gave me one thought about what changes when trust stops being the bottleneck and becomes the product itself. I'd rather explain it in the context of what you're building than try to compress it into a thread.
If you're interested, what's the best email to reach you on?
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.
Inner circle first is the honest move — public threads are better once you already know the language from people you trust.
Short write-up of the scoring method (no call needed):
Demo of how I productized that (~60s):
https://www.loom.com/share/5b178932cc9149f1ac30970e179e819b
Whenever you're ready to go wider than inner circle, happy to map a sample — call optional.
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?