Building for One User

Every tool I’ve built that actually works started the same way: I needed it and nothing else did the job right.

Prolific Personalities started because I wanted to understand personality archetypes in a way that existing frameworks didn’t capture. The content production system started because I hired someone and couldn’t transfer what was in my head. The Thought Manager started because I was tired of losing ideas to the gap between having a thought and finding the right app to put it in.

None of these started with a market analysis. None of them started with “what if I built a product that…” They started with friction — the specific, daily, annoying kind that you feel in your own workflow and can’t solve by switching to a different existing tool.

I’ve started to believe this is the only honest way to build.

The advantage of being your own user

When you build for yourself, several things happen that don’t happen when you build for an imagined audience:

You know what “good” feels like. You don’t need user research to tell you whether the output is right. You can feel it. When the content system generates a brief that sounds like your brand, you know immediately. When it doesn’t, you know that too. There’s no survey. No analytics dashboard. Just: does this feel like something I’d publish?

You use it at the edges. Most products get tested in ideal conditions. When you’re your own user, you test it at midnight when you’re tired and impatient. You test it when you’re trying to capture a thought before it disappears. You test it when you’re frustrated with the output and just want it to work. Those edge cases are where most tools fail and where the real design decisions live.

You iterate faster because the feedback loop is zero. I don’t need to ship a version, wait for user feedback, analyze the data, and plan the next sprint. I use the thing. I notice what’s wrong. I fix it. The content system is on version 13 not because I planned 13 iterations — but because each time I used it, I noticed something that could be better and changed it immediately.

You build what’s needed, not what’s impressive. There’s no investor to impress, no feature comparison chart to win. The only question is: does this solve my problem? This produces simpler, more focused tools. Not always prettier or more polished — but more useful per line of code.

The trap

The danger of building for one user is obvious: you end up with a tool that works perfectly for you and nobody else.

The content system is built around Prolific Personalities’ specific brand archetypes, voice rules, and content strategy. It’s not a general-purpose content tool. The Thought Manager is shaped around how my brain works — nonlinear, interrupt-driven, allergic to upfront categorization. Someone who thinks in structured outlines would hate it.

This is usually where startup advice tells you to “generalize.” Abstract away the specific use case. Build for the persona. Think about the market.

Maybe. Eventually. But I’ve watched enough products die by generalizing too early to be cautious about that instinct. The thing that makes a tool great for one person — the specificity, the opinionated defaults, the refusal to accommodate every possible workflow — is often the first thing that gets sanded away when you try to make it work for everyone.

The pattern I trust

Build the specific thing that solves your specific problem. Use it until you understand it deeply — not just the features, but the underlying need. Then look at whether the need is general even if the implementation isn’t.

The content system solves my problem of transferring editorial judgment to another person using AI tools. That’s specific to me. But the underlying problem — how do you make AI output consistent across a team when the context lives in one person’s head? — that’s general. The Thought Manager solves my problem of capturing thoughts without organizational friction. That’s specific. But the underlying problem — capture tools that demand structure at the wrong moment — that’s general.

The specific implementation is the prototype. The general problem is the product. But you can’t see the general problem clearly until you’ve lived inside the specific one long enough to separate the essential from the accidental.

So I keep building for one user. And I pay attention to which problems turn out to be mine alone and which ones keep showing up in conversations with other people who’ve been trying to solve the same thing with different tools that also don’t quite work.

That’s the signal I’m listening for.