I'm at $9 MRR with 1 paying user, considering a 6-week direction shift. Would you help me think through it?
Hey IH,
I'm 3 weeks into building axtra.app, which is a planner (for now). Currently it has 1 paying user and $9 MRR. I'm sitting on a direction decision that would commit the next 6-8 weeks of build time and I want to think through it with this community before I pull the trigger.
The current product is a fairly standard planner with AI quick-capture and a "rebalance my day" button. It works. The 1 paying user actually pays because the rebalance feature solves a real problem when their day breaks. But it's a feature, not a category.
Let me lay out the direction shift I'm considering.
I want to build a calendar that creates its own personal knowledge graph from every event you make. It extracts entities (people, places, activities, projects, organizations) automatically the moment you type. Future events referencing the same entity pull in accumulated context. The product gets smarter the longer you use it.
In practice, the Sam pattern works like this.
The first time you type "meeting with Sam", the calendar quietly asks "add an email for Sam?" You add it or skip.
The second time, "coffee with Sam Friday", his email auto-attaches. The calendar surfaces "last meeting with Sam was about Project Atlas" below the event.
By the third time, "Sam meeting in 1 hr", the calendar says "you promised him the feedback doc 2 weeks ago. send now?"
Same pattern works for places (Mocca's address auto-fills next time you mention it), activities (the gym pattern after 5 occurrences gets surfaced as a recurring suggestion), projects (Atlas events run 35% over duration, want a longer default block?), and organizations (Stripe interview tomorrow, here's what Stripe announced this week).
Plus a dashboard graph view where you sit at the center as a node. Every entity in your life radiates out as connected nodes you can explore. Less of a calendar, more of a map of your life with your schedule sitting on top.
I'm genuinely torn about three things.
First, I'm not sure if this is a real category or a feature dressed up as one. "Calendar with memory" sounds compelling but I worry I'm in love with the idea and not the evidence.
Second, the compounding moat. The pitch is that month 6 of using this is fundamentally different from month 1, because the graph is rich by then. But that's also the marketing-trap version of "network effects," easy to claim, hard to actually deliver if the early experience isn't strong enough to get people to month 6.
Third, the sequencing. The graph foundation alone is 6-8 weeks. Pattern learning, prep enrichment, pre-mortem nudges will take another 4 months on top of that. Roughly 5 months committed to one direction at this stage feels heavy when $9 MRR says I should maybe still be doing customer discovery instead of infrastructure work.
I would love to hear how you'd weigh in:
- Have any of you committed multi-month infrastructure bets at sub-$100 MRR? What broke and what worked?
- Does "calendar that builds its own knowledge graph" land as a real category to you, or feature-dressed-as-product?
- If you were me, what would you ship FIRST to falsify the bet cheaply before committing the full 6 months?
Thanks for the great post! I actually have a long-standing habit of writing down my personal schedule like this week's travel plans or a coffee chat with Sam on a paper calendar with a ballpoint pen, while keeping work or critical tasks on my digital calendar. As a fellow developer who has lived with this calendar-writing habit for so long, a question naturally pops up.
A 'calendar with a memory function'... honestly, the concept itself is flawless and incredibly cool. Living in the AI era, a service that organizes your memories and builds a calendar for you without you lifting a finger sounds amazing. If I were someone with a jam-packed schedule and endless back-to-back meetings, it would be a lifesaver. But if I'm just living a relatively ordinary, routine-driven life, it feels like feature bloat something nice to have but never actually used.
This makes me curious: for a 'calendar with a memory function,' who exactly is the target audience that justifies a $9 million monthly investment? It actually reminds me of a title I chose for an article published on my own platform: 'An App with 100 Features Won't Sell: The Secret Behind the "Nail Clipper" App That Swept #1 on Product Hunt.' At the end of the day, it really gets me thinking about how we should navigate this oversaturated market, where anyone can easily whip up an AI MVP over a weekend.
I appreciate you coming over to read it. And let me get one quick correction in first, because it sharpens your own question. It's $9 MRR, not $9 million. The product earns $9 a month total, one user. So "who is this for" matters even more than you framed it, because at this scale I can't afford to build for a fuzzy everyone.
You're right that the value is conditional. A calendar with memory is a lifesaver for a jam-packed life and bloat for a routine one. And your own habit shows exactly where that line sits. You keep personal life on paper because it's simple enough that paper works. Once paper stops working, when there are too many people, places, and half-finished threads to hold in your head, that's when the memory layer earns its place. You're telling me you're not the ICP, and that's useful.
The ICP is the person whose paper calendar would collapse under the volume, and that's solo founders, working parents, freelancers, and creators. They all share high entity volume and context-switching cost. It's those four specifically, not everyone.
Your "100 features won't sell" point is the discipline I need to hold. The honest version of this does one thing, it remembers, so you never re-enter context you gave it once. If it becomes a feature pile, you'll be right that it won't sell. So your comment pushes me toward narrowing, not broadening, which is exactly the read I was hoping for.
On your three questions:
Multi-month infrastructure bets at sub-$100 MRR almost always fail - not because the idea is wrong, but because you run out of feedback loops before you hit the moment of truth. The 1 user you have is your entire validation surface. Six months of building before they can tell you 'yes this is 10x better' is 6 months of compounding on a hunch.
'Calendar with memory' IS a real category instinct. The problem is you're describing the month-6 experience, not the day-1 experience. Most people don't stay long enough to reach month 6 in a new tool. The moat you're describing requires surviving the 'why is this better than what I have?' window in the first two weeks.
For falsification: build the knowledge graph pattern WITHOUT the calendar. Take your 1 paying user and manually maintain a context file for them -- every entity they mention, accumulated by hand. Show them what 'week 6 Sam' looks like today, in a shared Notion doc or Obsidian vault. If they say 'I'd pay 3x for this' after seeing it, you've validated the core insight without touching calendar infrastructure.
The simpler version of what you're describing already exists as linked-database Notion templates (people database, linked to projects, linked to meetings, linked to promises). The signal worth finding: do people pay for that static version before you build the AI-memory layer? If yes, the category is real. If not, the graph infrastructure won't save it.
What does your 1 paying user say when you show them a mockup of month-6?
Your month-6 vs day-1 framing really makes sense. I've been writing the spec from inside the moat where the graph is already rich, and hand-waving over the first two weeks where the product just feels like a slightly-fancier planner.
The falsification idea (manually maintain a context file for my 1 user, show them week 6 Sam in a Notion doc) tests the actual hypothesis better than the location-auto-fill MVP I was considering. I'm going to do this version.
And on whether people pay for the static linked-database templates that already exist, I haven't checked. I'm adding it to the cheap-test list before any code gets written.
Let me answer your question honestly. I haven't shown my 1 paying user any mockup yet. He pays for the rebalance feature and doesn't know about the entity graph direction. I'll show him a hand-built week 6 view this weekend and come back to this thread with what he says, even if it's not what I want to hear.
I'm not qualified to give advice (I'm a CS student just starting out, building a low-cost LLM API for SEA devs). But reading your post, a few things jumped out.
On your first question (infrastructure investment at <$100 MRR):
I haven't done it, but I've read enough failure posts to know that building infrastructure before finding product-market fit is how most startups die. The "build it and they will come" approach rarely works, especially for consumer products.
On your second question (real category or feature-in-disguise):
I think it could be a category, but only if the memory feature solves a real pain, not just a "cool to have." The example you gave (reminding you to send feedback before a meeting) is actually useful. The question is: how many people have that problem badly enough to pay?
On your third question (how to test cheaply before committing 6 months):
Could you build a simple browser extension that sits on top of Google Calendar? Just the "memory" part — when you create an event, it suggests context from past events. No graph visualization, no dashboards. Just one useful feature. See if people actually use it. If they do, you have validation. If not, you only lost 2 weeks instead of 6 months.
Either way, congrats on the first paying user. That's more than most people ever get.
I appreciate you taking the time. The "I'm not qualified" disclaimer tends to come from people whose comments are sharper than most.
The pain-vs-cool-to-have question is the right one. The "remind to send feedback before a meeting" example you flagged is the kind of thing I'd want most people to experience before deciding the category is real. And honestly I don't (yet) how many people have that problem badly enough to pay, which is exactly the gap I'm trying to close before committing.
Your browser-extension idea is actually a good one. I would definitely consider it, thank you. And I'm rooting for the LLM API you're building!