The One-Person Product

Every piece of software you use was built for millions of people. That sounds obvious, but think about what it actually means. Every feature, every default, every design decision is a compromise - a best guess at what works for the widest possible audience. The app doesn’t know you. It knows a statistical composite of everyone who might use it, and it optimizes for that ghost person.

This has been the deal for decades. Software is expensive to build and nearly free to distribute, so the entire industry optimized for reach. Build once, sell to a million. That’s the only math that worked.

I think that math is breaking.

The cost structure is flipping

The reason software had to chase scale was the upfront investment. You needed teams, time, infrastructure. Even a simple app took months. The only way to justify that cost was to spread it across as many users as possible.

But what happens when building gets dramatically cheaper? When someone with an idea and a clear sense of what they need can go from concept to working software in a weekend? The minimum viable audience shrinks. First from millions to thousands. Then from thousands to hundreds. And now, increasingly, to one.

AI didn’t replace developers. It changed the cost of building. The expensive part used to be implementation - writing the code, debugging it, wiring things together. That part is collapsing. What remains expensive is knowing what to build. Taste. Judgment. Understanding the problem deeply enough to know which details matter.

And nobody understands your problems better than you.

What you lose when you build for everyone

Think about the software you use every day. How much of it is actually the thing you came for, and how much is scaffolding?

Authentication flows. Onboarding screens. Settings pages. Notification preferences. Permission modals. Privacy controls. Data export tools. Update prompts. “What’s new” popups. Pricing tiers. Account management.

All of this exists because the software serves strangers. It has to handle a million different people with a million different contexts, devices, workflows, and expectations. So it builds an enormous layer of infrastructure just to manage the fact that it doesn’t know who you are or what you want.

Remove the strangers and most of that disappears. When the builder is the user, you don’t need onboarding because you already know how it works. You don’t need accounts because there’s only one. You don’t need preference screens because the preferences are baked in. What you’re left with is the actual function. The core thing. And it turns out that the core thing, without all the wrapping, is fast, light, and exactly right.

I’d guess that in most consumer software, at least half the codebase exists to solve the multi-user problem. The one-person product just doesn’t have that problem.

The gap that closes

Product teams spend enormous effort trying to understand their users. Customer interviews. Usability studies. Analytics dashboards. A/B tests. Journey maps. Personas. Feedback surveys. Beta programs. All of it is an attempt to close the gap between the person building the software and the person using it.

The one-person product closes that gap completely. It’s zero. The builder and the user are the same person. You don’t need to research what the user wants because you are the user. You know that you check this thing first in the morning. You know that this metric matters more than that one. You know the edge cases because you live them.

No amount of user research can replicate that. Interviews get you close. Observation gets you closer. But being the user gets you all the way there. Every design decision is instantly validated. The feedback loop is measured in seconds, not sprints.

This isn’t just for developers

Right now, the people building one-person products are mostly technical. But the circle is expanding. The tools are getting better, the barriers are dropping, and the gap between “I wish this existed” and “I built this” is shrinking for people who have no interest in becoming developers.

Think about the kinds of needs that exist out there. A teacher who wants a specific type of quiz generator that no ed-tech app quite nails. A parent who wants a chore tracker that works exactly the way their family operates. A small business owner who needs a dashboard that shows just the three numbers they care about. A hobbyist who wants a tool for cataloging something niche.

These needs have always existed. They’re too specific for any company to serve. The market for each one is tiny - sometimes literally one person. So they’ve always gone unmet, or people have settled for something that’s close enough but never quite right.

The emerging reality is that these people build their own. Not because they want to be developers. Because the cost of a custom solution drops below the cost of adapting to a generic one. At some point, it’s less effort to describe exactly what you want and have it built than to learn the workarounds for an app that almost does what you need.

The interesting tension

Here’s what I find genuinely interesting about this: it inverts a core assumption about software.

The conventional wisdom is that software gets better as it gets more users. More users means more feedback, more data, more revenue to reinvest, more edge cases discovered and handled. Scale is a virtue. This is mostly true for platforms, marketplaces, and social products - things that create value through network effects.

But for tools - the software you use to get things done - I’m not sure scale makes them better. It might make them worse. Every new user is a new set of requirements that has to be balanced against every other user’s requirements. Features get added for segments you’re not part of. Defaults get changed because the median user is different from you. The product drifts toward the average, which is another way of saying it drifts away from everyone.

A one-person product doesn’t drift. It can’t. There’s no average to drift toward. It stays exactly fitted to the one person it serves, and it can change the moment that person’s needs change. No roadmap. No prioritization. No ticket. Just fix it.

Where this doesn’t work

I don’t want to oversell this. One-person products work for tools - things with clear inputs and outputs where your needs are specific enough to encode in software.

They don’t work for social products. They don’t work for marketplaces. They don’t work for anything where the value comes from other people using it too. There’s a whole category of software that only creates value at scale, and that’s not going away.

There’s also the maintenance question. Every tool you build is a tool you have to keep running. APIs change. Operating systems update. Data formats shift. One custom tool is manageable. Ten might be a headache. Fifty is a second job. The long-term cost of ownership is real, and most people thinking about building their own tools aren’t thinking about year three.

And there’s an imagination gap. You have to be able to picture the solution before you can describe it. Most people with a specific need don’t think “I could build something for this.” They think “I wish there was an app for this.” Bridging that gap - from consumer to builder - is a cultural shift that’s just starting.

Where I think this is going

I don’t think one-person products replace traditional software. I think they fill a space that traditional software was never going to reach.

There are millions of needs that are too specific for a product, too small for a market, and too niche for any company to justify building for. These needs have always existed. They just weren’t economically addressable. Now they are. Not because someone decided to serve these markets, but because the people with the needs can serve themselves.

We’re moving toward a world where a meaningful chunk of the software people use daily is software they made. Not downloaded, not subscribed to, not recommended by an algorithm. Built, for an audience of one, because it was easier than settling for something close enough.

That’s a strange shift for an industry that spent fifty years optimizing for scale. But maybe the ultimate form of product-market fit was always this: the product and the market are the same person.