Your app is not the moat

Last week I showed a client my Obsidian vault.

We were talking about how to rewire product and engineering work for agentic workflows. Not which AI tool to buy. Not whether everyone should use the same chatbot. The harder question was what kind of operating system a team needs when more work starts moving through agents.

So I showed him mine.

Projects, areas, resources, archives. Meeting transcripts. Slack distills. Email and calendar signals. Content drafts. Client notes. Writing rules. Business preferences. Commands that read across the whole thing and regenerate the views I need to run the business.

It looks like a structured folder system of markdown files.

It is also the most important part of my workflow.

Not Obsidian, exactly. Obsidian is the current application I use to view it. The same vault is useful in Claude Code, Codex, or any text editor that can read a folder of files. Each tool makes it better in its own way, but the substance of the thing is not the app.

The value is the context, preferences, and workflows I have slowly gathered and structured. The meeting notes are useful because they connect to client files. The content drafts are useful because they sit next to the writing guidance. The commands are useful because they know where things live and what good output looks like.

Your app is not the moat.

That is what I almost said when I replied to somebody on Threads who asked whether Obsidian is really better than Notion.

Better for me? Absolutely. Better for her? I can't say.

The question was framed as Obsidian versus Notion.

I think that is the wrong comparison.

The choice is between letting an app become the place your work lives, or using apps as views over work you control.

For most of computing history, that distinction barely mattered. The company holding your data was usually the only thing that could do anything useful with it. You couldn't analyze all of your own emails. You couldn't slice your calendar history across years. You couldn't write a script to read every meeting note you ever took and pull out the patterns.

If a company got there first and built a passable interface, you stayed.

You weren't loyal. You were stuck.

That part has broken.

Why custody matters now

I want my data on disk because the model I run it through changes every quarter, and so does the harness around the model. The best setup for summarizing meetings today may not be the best setup for editing a newsletter draft, reviewing a client project, or planning a week. Sometimes the important choice is which model to use. Sometimes it is which environment around the model can actually do the job. The same underlying work might need a chat interface, a coding agent, a research assistant, or a text editor with an AI loop wrapped around it. The only way I get to evaluate any of them is if my work is portable enough to bring with me.

If my meeting notes live in a vendor's database and I can only see them through their app, I'm not evaluating what's possible. I'm evaluating what their product team decided to expose this quarter. That's a fine experience. It is not the experience of being on the frontier.

This is why I keep my whole life, personal and professional, in a structured vault of markdown files. Whatever AI tool I want to point at it tomorrow can read it the same way today's tool reads it. The plainness is the feature.

When I want a morning briefing, the command reads calendar events, recent meeting notes, emails, project files, and client context from the same vault. When I want to test a different model, I don't have to wait for a product integration or export flow. I point the model at the same files and see whether it gives me a better read on the business.

That answer is not for everyone. Plenty of smart people don't want to manage files, don't want to think about backups, don't want a folder structure on their laptop to be the source of truth for anything. Fine. The question is just whether you've thought about it. Most people haven't, because the question didn't use to matter. Now it does.

What you can vibe code and what you can't

The same question runs the other way on the company side, and that side explains a story you've been hearing more of in the last year.

The CTO of a company will vibe code, in a weekend, an internal version of some SaaS tool the company is considering purchasing or renewing.

The story usually gets told as a victory lap for whoever pulled it off. I think it shows something more important about the new landscape of software.

Whatever the company was buying, internal CRM, approval workflow, lightweight dashboard, wrapper, or form-and-list app, an engineer with a current frontier model can rebuild a workable version of it in days. The hard part of that software was figuring out what to build. Someone else already did that work. Bolt their problem-clarity onto the particulars of your own workflow and you can build something better. For you.

What that engineer can't do over a weekend is recreate the data the original company sits on.

The defensible thing is not the app. It is the seat at the data crossroads. Industry-wide transaction history. Cross-company benchmarks. Sector-wide patterns that get sharper every time another customer signs on and contributes their slice. None of that is a vibe-code job. None of that is summonable. That is an actual moat.

Taste still matters. Workflow matters. Trust matters. Distribution matters. A good product earns its place every day. But the app by itself is less defensible than it used to be. If the substance of the business is a wrapper, dashboard, form, workflow, or list view on top of data someone else owns, the surface is not enough.

The Granola test

I've been using Granola for over a year. The app is great. The UX is far superior to other options. None of that is what's going to keep them alive in three years.

What I think they're racing toward is creating a system of record for all of the things in an organization that never used to get to documentation. Making the oral history tangible.

If my whole team uses Granola, then patterns across our meetings become visible to a layer of analysis no one of us can do alone. Whose calls ran long this quarter. Which clients keep coming up. Which deals stalled and what language predicted it. Add a few more customers and now there is industry-level pattern recognition for, say, how SaaS sales calls actually progress, that you can't get anywhere else.

Add the shared layer of summarization skills the company has been tuning on millions of meetings, and a new content strategist on my team doesn't have to roll her own way of summarizing customer calls. The default Granola gives her is sharper than what she'd build in a week. Yes, she could build it. Most people won't.

That kind of moat lets you make a move that looks like a giveaway.

You don't have to fight your customers' off-ramps anymore. MCP access to the data, full exports, integrations that let people pull their content into whatever vault or agent they're running. Sure. Take it. Because tomorrow your system is going to be more valuable than it is today, and the version of yourself you ship next quarter is what you're really competing against. Customers don't stay because you trapped them. They stay because leaving means giving up the improvement loop.

The companies that haven't figured this out yet are the ones still treating the exit door as a competitive weakness. LinkedIn is the definitive example here. The network is powerful, but the product does not make my own professional context more useful to me. They can't let me do the things I want with my data there because their advantage depends on keeping my professional graph inside their interface. And I hate being stuck there. I hate that their tools to improve my profile are worse than what I can do in Claude Code or Codex and they actively make it hard for me to do.

The same test runs in both directions

These two halves ask the same question from opposite sides of the table.

If you're using a tool, the question is whether the service running on top of your data makes the data more useful than it would be sitting in a folder on your laptop. If yes, the tool earns its rent. If no, get custody back and find a tool whose answer is yes.

If you're building a tool, the question is whether your service is making the data more valuable in a way nobody can vibe code around. If yes, you can afford to be generous about how customers come and go, because what you're really selling is the next version of the improvement loop. If no, you're a UI shell sitting on top of someone else's data, and the engineer in their kitchen with Claude Code on a Saturday afternoon is going to rebuild you for free.

The app is not the moat.

The data is not automatically the moat either.

The moat is what your system learns from the data that nobody else can learn as quickly.