Introduction
In a few of my recent articles, I’ve been circling the same broader idea from different directions: AI lowers the cost of execution, which makes judgment, domain knowledge, and knowing what to build more important. I’ve looked at that through the lens of software development, asking better questions, and even what happens to human contribution when AI can create more of the output itself.
There is another consequence of that shift that I think is worth exploring on its own.
For most of software’s history, applications had to justify their existence by serving a market. Building software was expensive enough that you needed enough customers, users, or internal demand to make the investment worthwhile. That naturally pushed software toward generalization, i.e. products had to work well enough for a lot of people, even if that meant nobody got exactly what they wanted.
 |
| Software built for one. |
When the Market Size Can Be One
Earlier this year, TechCrunch described the rise of what it called "micro apps": small, highly specific applications people are building for themselves or a handful of others. One woman built an application to help her friends decide where to eat. Another person built a personal podcast translation tool. Someone else created an allergy tracker because she disliked the applications her doctor recommended. The common thread is that these applications were never meant to become products in the traditional sense. They only had to solve a very specific problem for the person building them.
The Verge described the same phenomenon as a "personal software revolution." For most of software history, users have had to accept the features and workflows that came with the product. Software was built for a broad audience, which meant it had to be useful enough for many people rather than perfect for any one of them. AI coding tools are starting to loosen that constraint by making it possible to create software for yourself without needing to justify the effort with a large user base.
I saw this happen in a much more mundane setting with someone close to me who recently started a small candle-making business. He had signed up for a commercial application that cost about $300 a year to manage things like inventory, testing, and formulas. Then, over a weekend, he started building his own version with AI. It did everything he had been paying for, but because he was building it around his own business, he could also add things that would never make it onto the roadmap of a commercial candle-management application. One example was integrating it with his AI-enabled smart glasses so he could ask for the formula for a particular batch while he was working.
That is what makes the example interesting. The application does not need 10,000 customers. It does not need a sales team, a product roadmap, or a market analysis. It only needs to be useful to him.
And because he has experience running a real production-oriented business, he is not just throwing features at the wall to see what sticks. He understands workflows, inventory, operations, and the kinds of information that matter when you are actually making and selling physical products. AI lowers the technical barrier, but the usefulness of the application still comes from knowing what the work looks like in practice.
That starts to change the economics of software in a very real way. The question is no longer always whether there is a large enough market to justify building something. Sometimes the market can be one.
When One Size Fits Us
Personal software is interesting on its own, but the idea becomes more consequential when the audience grows from one person to a small community of people who share the same problem.
GeekWire described a similar shift inside Microsoft and OpenAI. Instead of defaulting to spreadsheets, PowerPoint decks, or waiting for a development team, people are starting to spin up lightweight, bespoke applications around very specific needs. Microsoft executive Charles Lamanna described teams replacing static documents with small interactive web applications built around a particular workflow or decision.
I see the same thing internally at CData. People are using Claude to build lightweight interactive applications that pull data from enterprise systems through Connect AI and present it in ways that would be awkward, time-consuming, or sometimes impossible to reproduce in a traditional BI tool. One example is a Customer Success dashboard that combines product usage signals, account activity, and other operational data into a purpose-built interface designed to answer a very specific set of questions for a very specific group of people.
That is the same pattern GeekWire is describing. The difference is that these are not necessarily "applications" in the traditional product sense. They are small pieces of software built around a workflow because the people doing the work know exactly what they need to see and how they want to interact with it.
Daniel Miessler described a related idea as "self-software": people building their own versions of applications they previously paid for because the existing products were close, but never quite right. He also points out the obvious next step. Once you have built a tailored version that works better for you, there is nothing preventing other people with the same problem from wanting it too.
I saw that progression happen almost exactly that way in a niche retail community.
A group of mineral and gemstone sellers had been using platforms like Etsy and Shopify because those were the available tools. They worked, but neither platform was designed around the way this particular community actually sells. Etsy was built primarily around handmade goods, while Shopify is intentionally broad enough to support almost any kind of online store. That flexibility is useful, but it also means the software cannot be deeply tailored around the needs of one small category of seller.
One member of that community decided to build something specifically for them. What makes the story interesting is that she had no software development background. Instead, she treated access to a high-end AI subscription as a business investment and used it to build a mobile application tailored specifically to mineral and gemstone sellers. The application includes features that make sense inside that community because the person building it already understands how those sellers work, what they sell, and where the existing platforms create friction. Early testers have been enthusiastic about it.
That doesn’t mean Etsy or Shopify suddenly have a problem. Their job is to serve enormous and diverse markets, and that requires generalization. But it does show something that would have been difficult to justify economically until very recently: a niche that is too small to attract a traditional software company may still be large enough to support software created by someone inside that niche.
This is also where the idea starts to connect back to my earlier experience building a Stream Deck plugin with AI. I did not know TypeScript or the WebSocket protocol when I started. The important thing was that I knew what I wanted the software to do. In this case, the gap is even larger because the person building the application did not begin as a developer at all.
So perhaps the progression does not stop at personal software. Something built because "one size fits me" can turn into "one size fits people like me."
When AI Gets in the Way
There is an obvious temptation in all of this to assume that adding AI automatically makes software better. In practice, that assumption can fall apart pretty quickly.
That may be useful in some situations, but in this one it has the opposite effect. The notification has a very simple job: give me enough information to triage the message. By inserting an AI-generated layer into that space, Outlook actually gives me less of the information I was looking for. Here, the feature gets in the way of the workflow even if the AI behind it is working exactly as intended.
The same issue showed up in a much more serious setting: an AI-native eye clinic in China. Researchers built a system designed around AI from the beginning, but the technology itself was not enough. Performance improved when ophthalmologists supplied better-quality training data, and adoption improved only after the workflow was changed to reduce clicks and manual entry. The researchers ultimately described the challenge as one involving data quality, clinician engagement, workflow design, governance, and monitoring, not just model performance.
When one person is building software for themselves, they can change the application the moment something feels wrong. When someone is building for a small community they understand well, the feedback loop is still relatively tight. But as the number of users, workflows, constraints, and consequences grows, getting the fit right becomes much harder.
That is why I do not think the future is simply "AI everywhere." The better test is whether AI helps the software fit the work more closely than it did before. In some cases, that can be transformative. In others, it can simply add another layer between the user and the thing they were already trying to do.
Software That Adapts to Us
AI changes the economics because someone can now build software around a single business, a small community, or a very specific internal workflow without first proving that thousands of people want the same thing. Traditional software will still be the right answer for plenty of problems, and plenty of custom applications will still be bad. What has changed is the threshold for deciding that something is worth building.
That shift is easy to underestimate because the examples can look small. A candle-making app. An application for a niche seller community. A lightweight internal dashboard. But taken together, they point toward a different relationship between people and software. Instead of always adapting our work to the assumptions built into someone else’s product, we can increasingly shape the software around the way the work actually happens.
The interesting question may no longer always be whether there is a market for a piece of software. As the cost of creating software continues to fall, sometimes having a real need may be enough reason to build it.