There's a category of founder post that's been showing up more often in the last six months. The author has shipped a real product. The product uses AI. The author is now writing about the engineering work that went into not losing context — the patterns they had to invent, the substrate they built, the discipline required to keep the AI grounded.

The details vary. The framing converges: AI context is its own layer. You don't get it for free. You build it. You operate it. You evolve it.

What's striking about these posts isn't the conclusion — it's that founders are saying it. The work to articulate "this is infrastructure" used to happen inside platform teams at large companies. Now it's happening in public, in indie-hacker forums, written by people who shipped real products with five-figure user counts.

That's the kind of market education that pulls a category into existence.

What "context as infrastructure" actually means

It's worth being precise. "Context as infrastructure" doesn't mean a single fancy library. It means a few specific commitments:

There is a substrate layer separate from the application. The application talks to the substrate. The substrate stores, retrieves, and serves the user's context to whatever component (model, agent, UI) needs it.

The substrate has its own lifecycle. It's deployed separately from the app. It's monitored separately. It's backed up separately. It has its own performance characteristics and its own scaling story.

The substrate is the source of truth. When the app and the substrate disagree, the substrate wins. The substrate is what survives a re-deploy or a tool migration.

The substrate has a contract. Other tools, services, and even other apps can read from it under defined rules. It's not a private cache inside one application.

Indie builders are writing about all four of these — sometimes implicitly, sometimes explicitly. They're noticing that what they've built isn't "a feature inside our app" but "a layer underneath every interaction."

Why founders are noticing this now

A few forces are pushing indie builders to articulate context as infrastructure right now.

Customer expectations rose. Users now expect their AI tools to remember. Apps that ignore continuity feel obviously broken. The bar got raised from "smart model" to "smart model that remembers."

Multi-tool reality. Even within a single product's user base, customers use other AI tools alongside it. Context that lives only inside one app feels arbitrarily limited.

Operational pain. Hand-rolled in-app memory ends up reimplementing the same patterns badly: scopes, scopes, scopes, retrieval, dedup. Founders feel the duplicated work first.

Lessons from the platforms. Watching how Anthropic, OpenAI, and various MCP servers handle context, founders notice the substrate pattern recurring. It's easier to ship something similar than to keep inventing.

These four push toward the same shape. The product team realizes context belongs in its own layer. They build it (sometimes), they write about it (sometimes), and they start picturing a market for it (sometimes).

What this means for vault products

The vault-under-the-tools pattern is exactly what indie builders are describing — but as a product rather than something each builder has to roll themselves.

Vault products benefit from this market education in two ways.

They don't have to teach the category from scratch. When founders are already writing about context-as-infrastructure, vault products can ride the framing. "You're already building the substrate manually — here's the substrate, prebuilt, with the trust posture you'd want."

They can integrate where founders are already trying to land. Indie builders who articulate context-as-infrastructure tend to be the same builders shipping MCP-aware products. Vault products that expose themselves through MCP slot into the architecture those builders are already designing.

The positioning isn't competitive with indie builders' own substrate work — it's complementary. "Don't roll your own. Use a vault. Spend your engineering on the things that aren't the substrate."

What this means for indie builders considering rolling their own

For an indie builder reading the same forums and feeling tempted to build their own context layer: there is a reasonable case for using something off the shelf instead.

The context substrate is not your differentiator. Your product is doing something specific; the substrate is the boring part underneath. Rolling your own takes time you could spend on the product, and it doesn't get you a moat. Users don't pick your product because your substrate is yours; they pick it because your product solves something for them.

Using a vault gets you a few things you'd otherwise reinvent:

Local-first storage with encryption.
Scopes, permissions, and audit trails.
Cross-client exposure via MCP.
An export and migration story.
A UI for users to inspect and curate their own context.

If you build it yourself, you eventually build all of these, badly, while your real product waits. If you pick a vault, your product is the part of the stack you actually have insight into.

What "the vault-under-the-tools" pattern adds vs in-app memory

The in-app memory approach — building memory directly into your app — has a clear appeal: total control, no dependency, no integration overhead.

It also has a clear ceiling. The user's memory is locked to your app. If they use other AI tools (and they will), the memory you store doesn't help them there. If you ship a new product later, you re-implement the substrate.

The vault pattern trades some control for a different shape of value. The memory lives outside your app, in a substrate the user owns. Your app reads and writes from it. The user can use the same vault in other AI tools. You can ship a second product later and reuse the substrate.

For users, the vault pattern is more durable: their context survives your product's lifecycle. For builders, the vault pattern shifts the engineering investment toward the parts of the product that are differentiated.

What ships when this becomes the convention

If vault-shaped substrates become the convention, several things will get easier:

New AI apps ship faster, because they assume the substrate exists.
User trust transfers across products because the trust decision is about the substrate, not the app.
Cross-tool patterns become normal rather than impressive.
The memory and context features in big-vendor AI products get less load-bearing — they become one client among many on the same substrate, rather than the place all the context lives.

That's a healthy ecosystem shape. The current one — every app rolling its own substrate, each isolated from the others — produces fragmentation and lock-in. The vault-shaped one produces composability.

A short version

Indie builders writing about "managing your AI context" are describing infrastructure. They're hitting the same patterns at the same time. The vault-under-the-tools approach turns that infrastructure into a buildable product. The category is being defined out in public; the products that match the framing get a tailwind. For both builders and users, the move is to stop rolling context substrate per-app and start picking the one substrate that lives under whichever AI clients you use.