Rise of One-User Apps

One person. One problem. One app. Why this is viable now.

Like many, I have a challenge managing multiple personal calendars, and schedules alongside work calendars.

I tried everything. Every productivity app that showed up in a listicle, every ‘all-in-one’ tool that promised to fix exactly this problem. Some of them were genuinely good. Clean, well-designed, thoughtfully built. But none of them knew me. They knew a version of me — the average version, the persona some product team had sketched out in a user research session. They didn’t know that I need my mornings protected, that I think better mid-afternoon, that I have four calendars that can’t be merged for reasons that are annoying to explain, and that I need a very specific kind of nudge to actually respect my own schedule.

So I attempted to build one and it was surprisingly easy. A small system, nothing fancy. It does exactly what I need and nothing else.

And here’s the thing that stuck with me afterward: building it took less time than the last app I downloaded, set up, and eventually abandoned.

That’s a weird moment to sit with. The searching, the onboarding, the customization dance — it all added up to more time than just making the thing myself. And I’m not a full-time developer. I just had a problem with an AI assistant and a few hours.

I think that moment — when building becomes faster than finding — is one of those quiet shifts that doesn’t get announced. It just happens, and then you look back and realize the ground moved.

We’ve always measured software success based on number of users. I’m starting to think that metric is going to get a lot less interesting.

Here’s the idea

I’ve been calling them One-user apps. Software that someone builds for themselves, for their own use case, with no intention of it ever serving anyone else.

This isn’t entirely new. People have always hacked together personal tools — macros, scripts, Zapier flows. The difference now is speed and capability. What used to require a developer and a few weeks now takes an afternoon. What used to be a crude workaround can now be a genuinely good piece of software, tailored exactly to how you think and work.

The gap between having an idea and having a working thing has collapsed. And when that gap collapses, the whole question of ‘which app should I use’ starts to feel a bit quaint.

Take learning, as another example. If I want to get better at something — say, a new technical domain — every course I find is built for a general audience. It doesn’t know what I already understand. It doesn’t know where I keep getting tripped up. It moves at someone else’s pace, covers things I don’t need, skips things I do.

But if I build my own learning system — something that reads my notes, tests my gaps, generates quizzes around my actual weaknesses, and adjusts as I get better — that’s a completely different thing. It’s not a better version of the same product. It’s a different category entirely.

That’s what I mean by one-user apps. Not personalization as a feature. Personalization as the whole point.

Why this is actually happening now

For a long time, the gap between builder and user was enormous. Building software took expertise, time, infrastructure, and money. That gap forced a particular model: one team builds, millions of people use it. The economics only worked at scale.

AI didn’t just make building faster. It removed the expertise barrier. You don’t need to know how to code to have a working system anymore. You need to know what you want — which, it turns out, most people are pretty good at when it comes to their own problems.

And the infrastructure piece is moving too. Local models, edge compute, on-device processing — all of it is heading toward a world where your personal tools run on your own hardware, with your own data, without sending anything anywhere. In a strange way it rhymes with the old on-premises world, except now the premises are your laptop or the small computer on your desk.

This matters beyond privacy, though privacy is a big part of it. It means the cost of running a one-user app trends toward zero. No SaaS subscription. No cloud bill. No vendor relationship. Just a thing you built that runs and does what you need.

The number of apps in the world is about to grow a lot faster than the number of users. Most of those apps won’t be on any store.

What happened with the App Store

When the App Store launched, it created something genuinely new. A distribution channel that let a small team build something and put it in front of billions of people. The economics were wild. A two-person team could compete with a large company if they built the right thing.

That era produced an enormous amount of value. It also produced a particular shape of software: generalized, mass-market, designed to be good enough for as many people as possible. Which is another way of saying: not quite right for anyone in particular.

The app store model assumed a clean separation between the people who build and the people who use. That assumption held for fifteen years. I think it’s starting to break.

Not because app stores will disappear — they won’t, at least not soon. But because for a growing number of problems, for a growing number of people, the calculus has shifted. You used to search for an app, download it, configure it, tolerate its limitations, and pay for it monthly. Now you can describe your problem to an AI, iterate for a few hours, and have something that actually fits. Neither path is free. But one of them gives you something built exactly for you.

The interesting question isn’t whether this shift is happening. I think it clearly is, at least at the edges. The interesting question is what it means if you’re in the business of building software for other people.

Three things worth thinking about if you lead a technology team

I’m not going to pretend I have this fully figured out. But these are the questions I keep coming back to:

What do you own that someone can’t just build around? If your product is primarily an interface — a well-designed wrapper around capability that’s becoming more accessible — that wrapper is under pressure. The question is what sits beneath it. The data, the model, the proprietary signal, the network effect. Do you know, specifically, what that is? If a user rebuilt your product with AI over a weekend, what would they actually be missing?

Who is actually competing with you now? It might not be the company with a similar product roadmap. It might be your own users, with a free afternoon and an AI assistant. That’s a different kind of competition. You can’t out-feature it. You can’t out-market it. The only response is to be so deeply embedded in something they can’t replicate that building around you is harder than building on top of you.

Are you building for users — or enabling builders? The companies I think will do well in the next decade aren’t the ones with the best apps. They’re the ones that become the infrastructure other people build on. The value doesn’t disappear when users start building their own tools. It just moves upstream. The question is whether you’re positioned there.

My calendar system is still running. I’ve updated it a few times. It knows things about how I work that I never could have configured in a settings panel.

I’m not saying everyone will become a software builder. Most people won’t, at least not in any deliberate sense. But a growing number of people will, for specific problems that matter enough to them. And as the tools get better, that number goes up.

The shift I’m describing isn’t from one app to another. It’s from assuming that someone else will build the thing you need, to realizing that you might just be the right person to build it.

Some of your users have already figured that out. The rest are getting there.