How Do I Get a Second User?

I’m working on an organizational memory product. It’s a fancy way of saying documentation for agents, at scale, across the company, distributed so users don’t have to struggle to find the context.

I’ve built lots of rich context, and I could put you to sleep with anecdotes about how it’s helped the agents I’ve built and the research I’ve conducted.

But ay, there’s the rub: Me. Myself. I.

I have one user.

It’s a vexing product problem: how do you bootstrap the user base of a “0” product? AI makes it vexing-er-est.

My engineering teams are booked solid with “real” work. But since I got my hands on Claude in January, all of a sudden I can vibe-code. So I did.

And now it’s all locked on my laptop, because product managers don’t deploy production infrastructure.

How do I get a second user when my product is isolated like it’s 1999?

I have three ideas.

Option 1: Get another subject-matter expert

If the secret to my product is exceptional context, then my second user should also be a context generator: someone in my domain whose expertise complements mine.

But I have to make it worth their while.

They need to regularly use Claude or Cursor to explore our shared domain. Their contributions need to immediately improve their own work. Better yet, something they learn Tuesday should make my work better Wednesday—or a minute later.

There’s the technical challenge.

To move from an isolated laptop to two users working in tandem, I need a connected system with shared storage. Principle of least privilege and production-database best practices mean product managers can’t just spin that up themselves.

I need engineers.

Which brings me back to the problem I started with.

Option 2: Use the information schema

If the secret to success is getting context into the hands of as many users as possible, as fast as possible, then my second “user” could be anyone using an agent that checks comments on tables and views before writing a query.

That’s an easy way to scale. But it’s invisible, and there’s no feedback loop.

My users won’t necessarily know they’re using my context. They won’t know how to criticize it. And I won’t know whether it helped.

It also runs into the principle of least privilege. I’ve wanted to set comments on my tables and columns for years. Our platform team quite reasonably has that locked down.

Option 3: Hijack an existing MCP server

Okay, this one isn’t exactly an option available to everyone.

One of my engineering teams has a product that describes telemetry schemas conceptually. It happens to have an MCP server. And that MCP server happens to expose documentation—a big blob of text.

If the secret to success is getting context to users who care enough about data quality to go through the trouble of configuring an MCP server—and who might occasionally tell me when my context is wrong—then maybe I don’t need to build anything yet.

Maybe I inject table-level context into that big blob of text, drive adoption of the MCP server, and create an IM channel for feedback.

It’s not the architecture I designed.

But it might get me a second user.

I’m actually pursuing all three. One optimizes for creating context. One optimizes for distributing it. One might give me a little of both.

I have no idea which one will get me user #2 first.