Here's a marketing problem no one prepares you for: what happens when your product's success means people stop using it?
At Murror, our best outcome is when someone works through what's been weighing on them and doesn't need to come back for a while. They journal, they process, they gain clarity and then they go live their life. That's the whole point.
Many people have told me that being part of Gen Z comes with advantages we have time, energy, and plenty of opportunities to shape our careers in the AI era. And I do feel lucky to have grown up with technology, to have had early exposure and opportunities to learn and explore it.
But the AI era feels different. The shift is not only new, it s happening at lightning speed. Before I ve even fully adapted to working with AI, we re already seeing waves of layoffs where human roles are being replaced or reshaped by AI systems. And honestly, that creates uncertainty and anxiety not just for me, but for many people around us.
A new NBER paper tracks 500,000+ GitHub developers against their actual AI telemetry. The task-level gains are enormous and they mostly don't survive the trip to a shipped release. Across four app marketplaces: a sharp rise in new apps, no rise in total usage.
Most of the AI-productivity argument you've read this year is two camps shouting single numbers at each other. There's a paper out that makes both camps right and is more useful than either, and the revised version went up this month, so it's worth twenty minutes before you write your Q4 plan.
When we first launched Murror, our onboarding looked like every other app. Five screens. Set your goals. Pick your interests. Create a profile. Upload a photo.
14% of users made it through. The rest disappeared before they ever journaled a single thought.
Average AI product gross margin is 52% against the 80% that defined SaaS, and inference eats about 23% of revenue. Every growth instinct you inherited was formed in a world where your best user cost you nothing.
There's a rule most of us absorbed without ever being taught it: engagement is free. One more session, one more entry, one more day in the app pure margin. That rule is why "north star metric" articles exist, why every dashboard puts DAU at the top, why nobody ever asked you what your heaviest cohort costs. It held for twenty years because the marginal cost of serving a software user really was approximately zero.
The hard part of building a product moved in 2026 and most makers are still pouring their energy into the part that got easy.
There's a specific kind of quiet that happens about three weeks after launch. The app works. The landing page is clean. You shipped the whole thing in a weekend because Cursor and Claude Code let one person out-build a small 2020 dev team. And then... nothing. A trickle of signups from your own timeline, and then the graph goes flat.
There s one thing we re 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 I learn, ask questions, and clarify problems as much as possible, so the product we re building becomes better, clearer, and more convincing for our users.
To do that, I try to practice a few things consistently:
Apple's App Review Guidelines say you must disclose where personal data goes to third-party AI and get explicit permission first. A privacy policy paragraph doesn't do that.
Most of us read Apple's November 2025 guideline update, saw "AI" in it, and filed it under things for the big players. I did too, until I reread it as someone who sends people's journal entries to a language model.
A scan of 1.2 billion URLs found 15.3K validated prompt injections sitting on live pages, and about 70% of them are in HTML you never render. The fix most teams reach for - strip the page to plain text before you send it - is the worst of the four options tested.
Two of the last three things I've written here were about reading the primary document instead of the coverage. This one is about a paper almost nobody covered, which is worse, because it changes a line of code a lot of us shipped this year without thinking about it.
MCP just locked its biggest revision ever, and it quietly changes the unit of distribution from "a user opens your app" to "an agent calls your tool." That's a strategy decision, not an integration ticket.
A couple of weeks ago the Model Context Protocol shipped its final 2026-07-28 spec the largest revision since it launched. Most of the coverage was about the plumbing: it's stateless now, it runs on ordinary HTTP, the session handshake is gone. Real changes, and if you operate a server they matter. But that's not the part I'd flag for makers. The part I'd flag is what MCP has quietly become while everyone argued about transports: the way software gets used by agents instead of by people. There are close to ten thousand servers in the official registry now, MCP lives under the Linux Foundation with AWS, Google, Microsoft and Salesforce behind it, and this same release added MCP Apps servers can now render their own interactive UI right inside the agent. The protocol stopped being a developer curiosity. It became a distribution surface.
