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.
Reaching for it unconsciously validates utility for you, but not yet whether the shelf survives other people's workflows. I'd instrument two numbers during the three-day trial: items pinned per day and the percentage retrieved or reused within 24 hours; a shelf that only accumulates becomes another inbox. What threshold would make you change the onboarding before launch?
Those two numbers, pins per day and reuse within 24 hours, are exactly the kind of signal I'd want.
The real tension for me is that Tansei is built local first, no account, no telemetry, nothing leaves the Mac by default. So capturing something like that without quietly becoming the thing I said I wouldn't build is the part I haven't solved.
Curious how you'd approach it given you're clearly thinking about this properly.
Building for yourself gives you unusually fast feedback, but it can also hide the workaround knowledge only you have. I would document the exact trigger, time saved, and steps another person would need without your context. If those stay clear, the personal tool has a path to a repeatable product.
Agree! How you'd actually validate it in practice though, without leaning on tracking?
I'm guessing something like watching a handful of new users hit the tool cold, with no explanation from me, and seeing where they stall versus where it clicks?
Or would you approach it differently?
This is such a great message! My friend and I were searching for so long for an idea and ended up deciding that we should just start with a product we would use ourselves and that's where we have been able to actually create something instead of just thinking about what we would build.
Go for it, honestly. The only thing stopping you at this point is you. Sounds like you already found the actual unlock, building the thing you'd use yourselves, so the hardest part might already be behind you.
I'd genuinely spend time in forums and communities around whatever you're building, there's so much real advice sitting in there from people who've already hit the exact problems you're about to run into. Wishing you both all the best with it.
Context switching is such an underrated killer. I run a software company, a care home, and a cafe, and the thing that got me was not losing a snippet or a link, it was losing the thread on which business even deserved my attention that hour. I ended up building FounderFlow to solve my own version of this, so I get why you built Tansei for yourself first instead of an imagined user. The products that survive tend to start that way. Curious what the moment was where you realized this wasn't just a personal itch but something others needed too.
It's only going to get worse as the years go on with AI stacking even more tabs and tools into the mix, so if anything the timing feels more relevant, not less.
Also, running a software company, a care home, and a cafe at once is genuinely impressive, you should feel proud of that alone before any tool even enters the picture. I'll definitely check out FounderFlow, how are you distributing it, is it a Mac app?
On your question, honestly the shift for me was less a single moment and more a difference in standard. Building just for myself, I could get away with something that worked maybe 80% of the way there and still be happy with it, because I knew exactly how to work around its rough edges. The moment I thought about it being for other people too, I felt like I owed it 120%, polished and curated enough that someone who doesn't know its quirks could still trust it. That shift in standard is honestly what turned it from a personal fix into something worth shipping.
Lesson three really hit home. Same thing happened with the tool I built (a YouTube analytics extension) - I didn't fully trust it until I noticed I was checking it constantly for my own channel instead of digging through Studio's raw numbers myself. That's when I knew "using it before it's finished" is a real signal, not just a nice story you tell afterward.
The three-day trial before charging is a smart call too - most solo tools I see either lock everything behind a paywall immediately or give away too much for too long. Curious how you landed on three days specifically vs. a week?
Honestly a lot of it comes down to the tool being simple enough that you know within a few real sessions whether it fits how you work, it's not something that needs a week to figure out. Since it's a utility you use during your actual workflow rather than something you sit down and learn, that moment where you either reach for it without thinking or you don't tends to show up fast. A longer trial risked just delaying the same decision rather than making it clearer.
That, and like you said, people are tired of subscriptions, so the trial needed to feel like a real test, not a slow nudge toward a recurring charge.
Also curious about your extension now, what kind of YouTube analytics is it pulling, and is it Chrome specific?
I really liked your point about using the product before it was finished. I think that's one of the strongest validation signals a founder can get. If you naturally keep reaching for your own product, you're solving a real problem instead of chasing features. i'm Curious was there a moment where using Tansei changed your roadmap completely?
Less is more. The roadmap I'd been planning was all about adding capability, when the actual unlock was speed. I worked faster, not harder, once I started cutting and renaming things instead of adding more of them. After that I stopped asking "what feature should I add next" and started asking "what's currently slowing me down," which is a completely different roadmap to be working from.
I like that. It sounds like your product became better by becoming smaller, not bigger. Out of curiosity, was there a feature you were convinced users needed that you ended up removing completely?
Interesting counterpoint from the other side: I built my first paid product for a user I'm not (freelancers serving wholesale distributors), and the moment it felt real wasn't
unconscious use — it was a stopwatch. I timed the full client setup at ~40 minutes for something that takes 60–120 hours to build from scratch. When the gap is that measurable, you stop needing to trust your gut. So maybe the common thread isn't "build for yourself", it's "find a signal you can't argue with" — yours was reaching for the shelf without thinking, mine was a timer.
What's amazing is you needed to already understand the wholesale-distributor freelancer's workflow that deeply to even design a test like that in the first place. Mine never needed that outside understanding, just honest daily use of my own habits. Both get you to a signal you can't argue with, just from really different starting points.
You know you are passionate about your project when you use it every day yourself, or you just cant stop using it
Thats exactly right! Is there something you are working on right now?
The best validation is when you can't stop using your own product. If it solves your problem, you've already got proof of concept before anyone else tries it.
Have you ever felt this way about an idea before?
Truth! If you're experiencing friction, it's a sign that others may be as well. Obv, this isn't a full green light to all ideas, but it is a sign that an idea could be considered further.
Whether it's worth building further comes down to whether that friction is tied to something structural, a workflow lots of people actually share, versus something specific to your own tools or habits that nobody else would ever hit. I didn't really know which one I had until I started describing it to other people and watched them recognize the exact same moment of losing something mid switch. That's usually the real test, not whether you feel the friction, but whether a stranger recognizes it the second you describe it back to them.
The part about using it before it was finished is the test I trust most. I had that same moment with DictaFlow: I stopped opening a notes app when an idea hit and just held the hotkey without thinking about it. Build for yourself gets you to a real problem, but the next useful question is whether someone else reaches for it at the same moment, not whether they say they like the idea.
This is probably such a tricky part to get right, because the moment itself is invisible from the outside. Someone telling you they like the idea costs them nothing, but you can't exactly watch over their shoulder to see if they actually reach for it without thinking, the way you did with the hotkey or I did with the shelf. The closest I've gotten to a proxy for it is asking not "do you like this" but "when's the last time you actually opened it," since that at least forces a specific moment instead of a general impression. Still feels like the hardest thing to measure honestly, especially before you have enough people using it for patterns to show up on their own.
Really resonates, especially lesson three. My moment was similar: I run a speedcubing channel on the side, and I'd built a rough version of a YouTube analytics tool (Tubient) mostly to answer one question for myself, which videos were actually driving subscriber growth over the last 90 days, since YouTube Studio just doesn't answer that directly. I knew it was real the day I stopped opening YouTube Studio first and started opening my own tool instead, out of habit, not because I was testing it.
Also relate to lesson one. I wasted time early on trying to build for a "creator" persona I'd made up, and it didn't click until I admitted I was just building it to answer my own channel's questions. Good luck with Tansei, the "shelf at the edge of the screen" idea is a great one-sentence pitch, exactly what lesson two is describing.
That habit switch, opening your own tool before YouTube Studio without even deciding to, is exactly the tell. Not "I tested it and it worked," just quietly reaching for it first because it already earned the spot. That's the whole thing lesson three is trying to describe.
And the wasted time on an invented "creator" persona is such a specific, honest thing to admit. I did the same thing early on, trying to design for someone I'd sketched out in my head instead of just looking at what I actually did every day. It's a strange thing to unlearn, being told to think about "the user" when the fastest path is usually just being honest about being the user yourself.
Really appreciate the read on the pitch too, thank you. How does Tubient answer the "which videos drove subscriber growth" question well enough that you'd trust it over Studio for other channels too, or is it still tuned specifically to how your channel behaves?
Reaching for it without thinking is the strongest validation signal there is, and most founders never get it because they build for an imaginary user. The next test is harder: find 10 strangers with your exact context-switching problem and see if they reach for it too, because you-as-user proves the problem, not the market. And think hard about one-time pricing: utilities live or die on updates, and one-time revenue turns maintenance into a charity project.
These were such great insights! What is your background?
The 10 strangers test is fair, and honestly it's exactly what I'm doing right now, this whole week has been finding people with the actual problem and seeing if the shelf makes sense to them cold, not just to me. Early read is it lands for some and not for others, which feels like the honest answer at this stage rather than a clean yes.
The one-time pricing point is the one that actually sits with me more. I went one-time deliberately, mostly because I didn't want a new, unproven brand asking people to trust a recurring charge before they'd even used it once. But you're right that maintenance doesn't stop being real just because the revenue does, updates, macOS changes, bug fixes all keep happening whether or not new money is coming in. I don't think the answer is defending one-time pricing forever no matter what, it's more that if the model ever changes, I want it to be because the product's proven itself and genuinely needs that support, not because I panicked into it on day one. Appreciate you saying it plainly though, that's the kind of pushback that's actually useful.
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?
The clearest one: redesigning a process so the error becomes physically impossible, instead of patching mistakes one at a time.
I still run that kitchen today — plus two more restaurants, a pastry shop, and a bakery. Years ago, our best-selling dish had brutal margins because cooks kept overcooking or burning the meat during a long braise. We tried punishing people, timers, supplier changes... nothing stuck, because we were treating each burnt batch as an isolated mistake instead of asking why the process made mistakes inevitable. Switching to sous vide (sealed bag, controlled water bath) didn't just reduce errors — it made overcooking structurally impossible. Yield went up 28%, waste dropped, and it's still the most reliable dish on the menu, more than a decade later.
That's the same instinct I bring to building: when something breaks in EzWrite, I try not to just patch that one bug — I ask what about the process let it happen, and redesign so that class of error can't recur.
Amazing tip and 100% agree + useful story to learn from: "redesigning a process so the error becomes physically impossible, instead of patching mistakes one at a time."
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?