Designing for One

SEO Dash, which I'm launching soon, started exactly that way.

An afternoon of stitching together a handful of SEO tools I kept wishing lived under one roof, built fast and rough because the only person who'd ever open it was me.

Six hours in, it already did most of what I needed, and it felt fantastic. That building-for-one high is real, and it's worth being honest about why it feels so good before talking about what it quietly costs.

The Most Honest Way to Build

When you build for yourself, you can't lie to yourself.

That sounds obvious, but it's really the whole thing.

Every other kind of product work involves some amount of guessing about what other people want, and guessing leaves room for wishful thinking. You can convince yourself a feature matters and you can tell yourself users will figure it out.

But, you can ship something mediocre and then hide behind the idea that the market will validate it eventually.

An audience of one removes all of that. You are the user, so you know instantly whether the thing is good, because you have to live with it. There's no committee, no stakeholder, no users, no persona to hide behind.

Scratching your own itch hands you a kind of automatic product management, because the priority list is just obvious. You build the thing you need next and in the order you need it. And the cool thing is that you always know what that is.

This is why the tools people build for themselves tend to be so coherent. Your taste is the entire spec and nothing gets watered down in a meeting.

The result has a point of view, which is the thing I keep coming back to as the mark of software worth using. A product built by one opinionated person for that same person is about as opinionated as software gets.

The whole open source tradition is built on this instinct. The phrase itself comes from Eric Raymond's writing on scratching your own itch, the idea that the best tools come from a person solving their own problem and then leaving the solution out where others can find it.

And then, if you're lucky or unlucky enough, someone else wants in.

The Selfishness That Makes It Good

This part honestly took me a while to see clearly.

Every shortcut you take when building for yourself is a small bet that nobody else will ever need to understand this. Little wagers like:

• The cryptic button label that makes perfect sense because you know what it does
• The workflow with no instructions, because you invented the workflow
• The screen that never shows an empty state, because you've never once seen it empty
• The error you never handle, because you already know not to do the thing that triggers it

Each of those is a tiny act of trust that the audience will stay at exactly one person.

That trust is what makes the tool fast to build and pleasant to use.

It's also a wall, one you don't notice you're stacking brick by brick, because from the inside it looks like nothing at all. It just looks like the thing working.

The reason it looks like nothing is a genuine quirk of how your brain works. Once you know something well, you can't unlearn it, and you lose the ability to imagine not knowing it.

Psychologists have a name for this, the curse of knowledge, and the unsettling finding is that it barely responds to effort.

Being told about the bias doesn't fix it. Being asked to consider the beginner's perspective doesn't fix it.

The expert simply cannot re-create the newcomer's state of mind, because the difficulty they'd need to imagine no longer exists for them. Interesting stuff, right?

So building for yourself lets you skip the hardest part of design, which is picturing someone who isn't you. That skip feels like pure velocity in the moment, while functioning as empathy deferred, pushed down the road to a version of you who might have to pay for it later.

The Moment Someone Wants In

When SEO Dash caught a little wave on X, the interesting thing wasn't the list of features people asked for.

It was the negotiation that started up in my own head.

Because letting people in means giving up the exact thing that made the build so fun. The purely selfish version, where the only taste that mattered was mine, quietly ends the moment a stranger's confusion becomes my problem.

Now I'm designing for someone I have to imagine rather than someone I already am.

Every one of those little bets I made, every place I trusted the audience would stay at one, comes due at once.

This is where a lot of build-for-one projects stall, and I don't think it's usually a technical problem. It's that the builder discovers they don't actually want the second job, the one where you write the empty states and explain the workflow and rename things for people who weren't in your head the first time around.

Skilled developers rarely see the product the way a newcomer does, which means the work of letting people in is mostly the work of overriding your own instincts.

Some builders love that shift.

They light up at the puzzle of making a thing legible to strangers, and the empty first-run screen becomes the interesting problem rather than the annoying one. Other builders resent every minute of it and just want their tool back.

Neither reaction is wrong. But which one you have tells you something real about what you were actually building, and whether you want it to grow up.

Not Everything Should Grow Up

Preflight is the counterexample I keep in my back pocket.

I built it for the same selfish reason, a small tool to catch the dumb mistakes I kept making right before launching a site, the stuff I always forgot at the worst possible moment.

Built for one, scratching a very specific itch of my own.

But I initially open-sourced it instead of turning it into a full-fledged SaaS product, and that was a real decision, not a default. Open-sourcing a tool is a way of saying here is my thing, it works for me, help yourself if it helps you.

It hands the tool over as-is, on the builder's terms, without signing up for the job of making it comfortable for strangers.

Nobody who clones a repo expects onboarding. Nope, they expect a README and the same rough edges you live with.

That's a very different fork from the one SEO Dash took. Same starting point, opposite destination:

One tool became something I'm shaping for other people to pay for and rely on. The other stayed a gift, useful precisely because I never had to sand it down for an audience. The freedom to keep a tool selfish is underrated.

Remember, not every itch you scratch needs to turn into a support inbox.

What Actually Changes

When you start something for yourself, the honest question has nothing to do with whether other people could use it. Plenty of things could be used by others.

The real question is whether you're willing to stop building for you and start building for them, because those are two different jobs that happen to begin with the same afternoon.

The tool doesn't change on the day someone else wants in. You do, or you decide you'd rather not. Both answers are fine, and the only real mistake is refusing to notice which one you're giving.

So build the selfish version first.

It's the most honest draft you'll ever write, the one where you can't fool yourself about whether the thing is any good.

Just know that the moment you let a second person in, the job quietly changes. You stop extending the tool and start rebuilding every assumption you made back when you were the only one who mattered.