... Every pitch deck I see right now has the same promise: we help you do X faster with AI. Faster emails. Faster code. Faster decisions. Faster everything. But here's what I've noticed after two years of building Murror: the AI products people actually keep using aren't the ones that save them time. They're the ones that make them stop and think. We obsessed over speed in our early versions too. How quickly can we generate ... ... output speed, but the products people emotionally connect with are usually the ones that create clarity, reflection, or even discomfort in a meaningful way. That s the part users remember and come back for. Comment from Mona Truong(@monatruong_murror

... Most product teams track acquisition, activation, retention. The usual funnel. We track all of that at Murror too. But there's one metric we started paying attention to that changed how we think about growth entirely: how often users talk about themselves differently after using the product. Not NPS. Not referrals. Not even engagement time. We look at the language shift. When someone starts a session saying "I don't know why I keep doing this" and ends it saying ... ... need to be re-engaged with push notifications or discount emails. They come back because the product changed how they see themselves. We started noticing this by accident. Our best word-of-mouth didn't come from users saying "Murror

... There's a pattern I keep noticing across the AI products that actually stick with people vs. the ones that get tried once and forgotten. The forgettable ones try to be impressive. They show off what the model can do -- generate faster, automate more, produce output at scale. And they're genuinely cool for about 15 minutes. The ones that last? They help you see something about yourself you couldn't see before. I've been thinking about this ... ... while building Murror

... product teams run surveys. We did too. We'd ask things like "What features would you like to see?" or "How would you rate your experience?" And we'd get perfectly reasonable, perfectly useless answers. The turning point for Murror came when we stopped designing around what people said they wanted and started paying attention to what they were avoiding. Here's what I mean: in our app, users can share stories and reflect on their emotions. We noticed that ... ... honest with yourself). For anyone building products that touch on personal growth, health, learning, or relationships -- have you found this to be true? That sometimes the "harder" experience is actually the better one? Comment from Alper Tayfur(@alpertayfurr): @monatruong_murror

... push notification saying "We miss you!" Instead, we reached out and asked one question: why did you stop? Their answers surprised us. One user said she had a difficult conversation with her partner using what she practiced in Murror, and it went better than any conversation they'd had in years. She just hadn't needed the app since. Another said he started noticing his own emotional patterns without opening the app. A third told us: "I stopped because ... ... understand themselves better, the real win might be how confidently they leave. We started tracking what we call "quiet confidence" users who reduce usage but whose referral rates and satisfaction scores actually go up. Turns out these users recommend Murror

... right now that worries me: the goal is to make AI the relationship. AI friends. AI therapists. AI partners. The pitch is always the same humans are complicated, AI is easy. No judgment, available 24/7, infinitely patient. But at Murror, we kept asking ourselves: what happens when the user closes the app? If the best version of their emotional life only exists inside our product, we haven't solved loneliness we've just made it more comfortable. So we took ... ... difficult conversation the app helps you understand what you're actually feeling and why, so you can show up more clearly with the real person. After a misunderstanding instead of venting to an AI that always agrees with you, Murror

... Most software wants you to come back every day. The business model depends on it. More sessions, more engagement, more opportunities to monetize. But what happens when your product's purpose is to help someone understand themselves better? At Murror, we've been wrestling with a paradox: if we do our job well, users should eventually need us less not more. Early on, we designed features to maximize return visits. Push notifications after 24 hours of inactivity. Streaks. Daily prompts ... ... made real progress on something, it explicitly tells you it's okay to step away. 3. We shifted our north star metric from daily active users to "life moments influenced" did the user actually apply something from Murror

... product in the mental health and self-awareness space: if you're doing it right, your users should eventually need you less. Most product teams optimize for stickiness. More sessions, more time in app, more daily returns. But at Murror, we've been wrestling with a different question what if the goal of our product is to help someone build enough self-understanding that they don't need to open the app as often? When someone uses Murror

... first year of building Murror, we optimized for the same metrics every other app optimizes for: daily active users, session length, screens per visit. The dashboard looked healthy. Usage was growing. We felt good about it. But something was off. Our most engaged users were not our happiest users. People who spent the most time in the app were often the ones who left the harshest feedback. Meanwhile, users who opened the app twice a week for five minutes were ... ... metrics with what we called "outcome metrics." Instead of tracking how long someone stayed, we tracked whether they reported feeling more clarity after a session. Instead of measuring return frequency, we measured whether people said they applied something from Murror

... first year of building Murror, DAU was the number we checked every morning. It was the first thing on our dashboard, the first metric in every team meeting, and the number we used to judge whether a feature was working. Then one day we noticed something strange: our DAU was climbing, but our NPS was dropping. People were opening the app more often, but they were less happy with it. Some of our most engaged users were showing signs ... ... what we started calling "compulsive checking" opening Murror

... When we first started building Murror, I spent a lot of time studying other AI wellness apps. I tracked their features, analyzed their onboarding flows, and mapped out where we could differentiate. I thought our competitive advantage would come from being smarter, faster, or more accurate than them. I was completely wrong about where the real competition was. Our biggest competitor

... months, our most requested feature at Murror was a chat function. Users wanted to talk to the AI the way they talk to a friend. It seemed obvious. Every competitor

... feel interchangeable? You open one, you open another. Different logo, different color scheme, same experience. A text box. A chat interface. Some version of "ask me anything." The wrapper changes but the feeling does not. When we started building Murror, we almost fell into this trap. Our first instinct was to build the most capable AI assistant we could and then figure out the positioning later. The logic seemed sound: better technology equals better product. But here is what ... ... what does this person need to feel, understand, or accomplish in this moment?" That reframing changes everything. It changes the interface, the pacing, the tone, even when the AI chooses not to respond. For Murror

... When we first started adding AI features to Murror, we built what we thought users wanted: sophisticated emotion detection, detailed mood analytics, and smart pattern recognition that could tell you exactly how your week went in a neat little chart. We were proud of it. The tech was solid. The accuracy was impressive. And almost nobody cared. Here is what we missed: users were not coming to Murror

... Everyone tells you to ship fast. Move fast and break things. Get to market before someone else does. I believed this for a long time. When we were building Murror, speed was everything. We pushed features weekly, sometimes daily. We celebrated every deploy like a small victory. But here is what nobody warned me about: shipping fast without learning is just organized chaos. We shipped a mood journaling feature in three days. It looked great in our demo. Users opened ... ... real daily use. The "constraint before speed" insight you mention is real forcing ourselves to answer "what s the one thing this feature can break" before shipping saved us from several own goals. The broader point about iteration speed vs

... Everyone is talking about vibe coding right now. Let AI handle the code while you focus on the vision. It sounds revolutionary. So we tried it. For one week, our team at Murror used AI coding tools for everything. New features, bug fixes, refactoring. We wanted to see if it could genuinely speed up our development cycle or if the hype was getting ahead of reality. Here is what we found: Day 1-2: Euphoria. We were generating components ... ... that they change what matters about being a developer. The value is no longer in writing code. It is in knowing what code to write and, more importantly, what code not to write. For a product like Murror

... from products people come back to every day. It is not a feature. It is not a notification. It is the feeling that the product remembers who you are. I have been thinking about this a lot while building Murror. We spent so much time on acquisition, onboarding funnels, and activation metrics. But the thing that actually moved our retention numbers was something much simpler: continuity. When a user opens Murror

... When we started building Murror, I made the same mistake most AI founders make: I marketed the technology. "Powered by AI." "Smart algorithms." "Personalized insights." All the buzzwords. And you know what happened? Crickets. The turning point came when I stopped explaining what Murror

... When we started building Murror, we did what most technical founders do: we disappeared into code for months. We built an emotion analysis engine. We refined our NLP pipeline. We designed beautiful dashboards. We were so proud of what we had made. Then we put it in front of real people. The first 50 users broke every assumption we had. They did not care about the sentiment accuracy score we spent weeks perfecting. They did not use the features ... ... first test your product, see if there is traction and if users are ready to buy. Getting feedback early changes everything, especially seeing how users actually behave, not just the what they say! Comment from Mona Truong(@monatruong_murror

... When we were building Murror, we spent months perfecting our AI emotion analysis engine. Deep NLP pipelines, sentiment layers, the whole thing. We were so proud of it. Then we launched, and you know what users kept telling us they loved? The simple daily check-in prompt. A single question that asks "How are you feeling right now?" before showing them anything else. It took maybe two days to build. The AI engine took six months. I've seen this ... ... launched with just the engine and no check-in, I don't think anyone would have cared. What about you? Have you ever been surprised by which feature your users loved most? Comment from Mona Truong(@monatruong_murror

... would need to reach a break even. - How much revenue you want to get. That could help you shape the target of your commercial services. Comment from M nevver (@munevver_ertuncccc): I like the way you framed it around general vs tailored value, that s a really clean way to think about it. For products, it often feels similar: free should help users understand the value, while paid should unlock outcomes they can t easily get on their own. The tricky ... ... genuinely hard when you're building for people going through something difficult. with Murror

... really good at as builders: we constantly try to improve our work and our product every single day. But an honest question I often ask myself is: do we put the same effort into updating ourselves? At Murror , we re a small team of around five people. For me, it s important not only to improve the product, but to continuously update my mindset, skills, and learnings and share them openly with the team. I try to communicate everything ... ... Understanding what I want, what I need, and how to move forward in a way that feels sustainable. How do you combine personal growth and product growth in your own journey? Comment from Nika(@busmark_w_nika): @monatruong_murror

... same year I left Google s Mountain View HQ where I was working on subscription experiences used by billions to pursue Murror, two engineers also left Google to build Character AI. Their early prototype raised safety concerns, but the idea evolved into a platform where people could create virtual characters such as AI companions, assistants, or friends. We started from similar places, but chose very different paths. Character AI focused on moving fast to meet market demand and scale quickly ... ... then kids committed suicide using the product. Murror

... defeated, but because I understand that they are projecting their emotions onto me. Many problems could be resolved if we learned how to regulate anger more mindfully. This realization is also what led me to reflect deeply on Murror, and why it exists in the first place. Murror

... help. I couldn t even look at myself without feeling lost. 3/ In that darkness, I made a promise: If I ever get out of this I want to build something that helps others feel less alone. Murror became that promise. 4/ Murror