Stop Shopping for Software. Start Describing It

For about forty years, getting software meant shopping for it. You had a problem, you went looking for a product that solved it, and you settled for whatever came closest. Close enough became the whole experience of using a computer.

That arrangement is quietly ending. The question is no longer "what app does this?" It's becoming "can I just describe what I want?" And more and more, the answer is yes.

This isn't a prediction about some far-off future. It's already showing up in ordinary places. People with zero coding background are building small tools for themselves in an afternoon. A student builds an app to settle where her friends should eat. A parent builds a chore tracker for the kids. Someone with a health scare builds a simple logger to record when their heart does something strange, so they have real notes for the doctor instead of vague memories.

None of those people are software developers. They just described what they needed to an AI, went back and forth a few times, and ended up with a working thing.

What "personal software" actually means

Tech folks have started calling these "micro apps," or sometimes "personal software." The names matter less than the idea behind them.

For most of computing history, software had to be built for millions of people to be worth building at all. Someone had to fund it, ship it, market it, and support it. That economics meant every product was a compromise. It had to work for the average of a huge crowd, which means it never quite worked for you.

Personal software flips that. When the cost of making a small tool drops close to zero, it suddenly makes sense to build something that only one person will ever use. You. Your team of four. Your household. The audience is tiny on purpose, and that's the point.

Think about how strange that would have sounded a few years ago. Building an app just to solve your own annoyance for a month, then throwing it away? That's like commissioning a custom suit to wear to one dinner. Now it's just Tuesday.

Why this changes the way you think about problems

Here's the shift that sneaks up on people. When software is something you shop for, your problems get shaped by what's available. You have a weird, specific workflow, but there's no product for it, so you bend your workflow to fit a product that was built for someone else. You learn to live with the friction because the alternative, hiring a developer, costs more than the problem is worth.

When software is something you describe, that whole calculation changes. The friction that used to be "just how it is" becomes a thing you can actually fix.

A few examples of the kind of problem that used to be too small to solve:

• The spreadsheet you rebuild by hand every Monday because no tool imports your data the way you actually use it.
• The three apps you copy and paste between because none of them talk to each other.
• The report your boss wants in a format that no software produces, so you reformat it manually every single time.
• The little calculator you wish existed for your specific pricing, your specific margins, your specific business.

For decades, the answer to all of these was "deal with it." The problem was real but too small to justify a custom build. That entire category of problem is now solvable in the time it takes to explain it clearly.

The skill that suddenly matters more

If you've read this blog before, you know we keep coming back to one idea: the people getting the most out of AI aren't the technical ones. They're the curious ones who ask good questions. Personal software is where that becomes obvious.

Building a small tool by describing it is basically an exercise in knowing what you actually want. That sounds easy. It isn't. Most of us are surprisingly fuzzy about our own processes. We do things by habit and never examine them. The moment you have to describe a workflow clearly enough for an AI to build it, you find out how well you understand your own work.

That's the same muscle behind getting good answers in general. It's why we've argued you should stop treating AI like a search engine and start treating it like a collaborator you can think out loud with. The person who can clearly say "here's what I do, here's where it breaks, here's what I wish happened instead" is the person who ends up with useful tools. The person who can't stays stuck with off-the-shelf compromises.

Clear thinking was always valuable. Now it has a direct payoff you can hold in your hand.

This is the same wave, from a different angle

We wrote recently that making things got cheap and taste got expensive. Personal software is that exact idea pointed at tools instead of content.

When anyone can generate a working app, the app itself stops being the scarce thing. What's scarce is knowing which tool is worth building, what it should actually do, and when a scrappy one-week version is enough versus when you genuinely need something durable and secure. The building got cheap. The judgment got valuable.

That's worth sitting with, because it's the opposite of how software used to reward people. It used to reward whoever could write the code. Now it increasingly rewards whoever understands the problem best.

The honest limitations

None of this means everyone should go build their own version of everything. There are real reasons to be careful, and pretending otherwise would be doing you a disservice.

Security is a genuine concern. When people with no technical background build apps quickly, they often don't know what they don't know. Recent reporting has already flagged a rise in security holes as more non-developers ship apps built this way. A personal tool that only you use and that holds no sensitive data is one thing. A tool that touches customer information, payment details, or anything regulated is a different animal entirely. That's exactly where "close enough" is not close enough.

Disposable is a feature, not a bug, but know which one you're building. A lot of personal software is meant to be temporary. It solves a problem this month and gets thrown away. That's healthy. The trouble starts when a throwaway tool quietly becomes something your business depends on, without anyone deciding it should. If a tool is going to carry real weight, it deserves real thought.

Some things still need professionals. Building a quick tracker for yourself is not the same as building the system that runs your company. The fact that you can describe a lot of software doesn't mean you should build all of it. Knowing the difference is part of the new skill.

None of these limitations cancel the shift. They just define its edges. The smart move isn't "build everything yourself" or "ignore all of this." It's learning to tell the difference between the problems you can now solve in an afternoon and the ones that still deserve care.

What to actually do with this

You don't need to become a builder overnight. But there's a small habit worth starting this week.

Keep a running list of the tiny annoyances in your day. The little repetitive tasks. The "I wish there were a thing that just did X." The manual steps you've accepted as permanent. Don't try to solve them yet. Just notice them and write them down.

That list is a map of the problems that used to be too small to fix. A year from now, more of them will be solvable by simply describing what you want. The people who thrive in this shift won't be the ones who learned to code. They'll be the ones who already knew, in plain language, exactly what they wished existed.

The age of settling for close enough is ending. The age of describing what you actually want is starting. The only real question is whether you know what that is.