When the user becomes the competition
I built a small app last month that nobody else would ever want to use.
It logs workouts, sleep, daily steps, and my supplement stack. It pulls in blood panels from my GP across metabolic health, inflammation, and organ function, around a few dozen markers, with the medical context that comes with each one. It factors in body composition, VO₂max, and resting heart rate. The home screen shows one number: my biological age, derived from all of it.
I used Lovable. It took a few evenings.
I'm not sharing this because I think it's impressive. I'm sharing it because of what it made me realize about a shift that's been happening quietly, and what it might mean for the software industry in general and for product thinking specifically.
The threshold that shaped everything
For a long time, software got built when enough people had the same problem. That threshold wasn't arbitrary. It existed because building software was expensive. You needed engineers. You needed time. You needed a distribution strategy. The economics only worked if you could spread those costs across a large enough user base. So the minimum viable audience determined what got built.
That logic shaped everything downstream: what products existed, how they were designed, who they served, and what compromises users had to accept. If your use case was too specific, too personal, too niche, you had two options. Find something close enough and adapt your behavior to fit the tool. Or do without.
Most people adapted. We all have. We use the health app that tracks the metrics it tracks, not necessarily the ones we care about. We use the productivity tool designed for a team of twenty when we need something for one. We use the note-taking app that organizes things the way its designers thought notes should be organized. The gap between what a product does and what we actually need has always been part of the deal.
That deal is changing, and for a specific category of tool, it's changing fast.
What's actually happening
The cost to go from "I need this specific thing" to "this exists" has dropped to almost nothing for lightweight personal tools, the ones that sit closest to how you actually live. Not for enterprise software. Not for anything that requires complex infrastructure, regulatory compliance, or deep integration with external systems. But for the personal layer, the access threshold is quietly collapsing.
Lovable, Cursor, Replit, and tools like them didn't just make coding faster. They changed who can participate in the act of building. You don't need to be an engineer or have a team. You need a clear idea of what you want and enough patience to iterate. The bar for entry has moved from technical skill to product thinking.
That's a meaningful shift because product thinking, the ability to define a problem precisely and reason about what a solution should do, is much more widely distributed than engineering skill. Most people who have specific software needs they can't meet already have the cognitive tools to specify what they want. What they've been missing is the ability to build it.
What this means for existing products
If you run a consumer software product today, you are probably not thinking about your users as potential competitors. That has always been a safe assumption. It is becoming less safe for a specific category of products.
Apps that justified their subscription price by being the only viable option now face a different kind of competition, not from better-funded startups or platform encroachment, but from the user themselves.
This is especially true for lifestyle and personal productivity tools. The more personal and specific a software need is, the more a general-purpose product has to compromise to serve it. And the more it has to compromise, the more motivated a user with a very specific need is to build their own version, if building is now accessible to them.
I'm not predicting the death of consumer software. Most people will not build their own apps, and that's fine. General-purpose tools will always serve the majority of use cases well enough. But the long tail of dissatisfied power users, the ones who churn, who leave reviews about missing features, who maintain elaborate workarounds, that group now has an exit option they didn't have before. Some of them will take it.
What this means for product thinking
The personal health dashboard I built is genuinely better for me than any existing product. Not because it's more sophisticated, but because it makes no compromises. It tracks exactly what I care about, displayed exactly how I want to see it, with no features I don't need and no business model creating pressure to surface things I didn't ask for.
That specificity is only possible because it was built for an audience of one. No product team could justify the engineering investment for one user. But I could justify a few evenings.
The implication for product teams is uncomfortable but worth sitting with. The features users want most are often the ones most specific to their situation, the ones that require deep understanding of individual context and behavior, the ones that would serve a small enough segment that they never make it onto a roadmap. Those features are increasingly buildable by the users themselves.
Products that thrive in this environment will probably be the ones that understand what they can do better than the user can: scale, reliability, integrations, data aggregation, social features, anything that requires infrastructure or network effects. The purely personal functionality, the idiosyncratic and deeply individual, that's increasingly contestable territory.
What I don't know
I want to be honest about the limits of this observation.
I don't know how far this goes. The people who will build their own tools in the near term are still a small and specific group: technically adjacent, curious, willing to spend evenings on side projects. That's not most people.
But the tools are getting better and faster. The gap between "person who can specify what they want" and "person who can build what they specified" is narrowing every cycle. And historically, when a capability goes from scarce to abundant, the things that depended on that scarcity tend to change in ways that are hard to predict in advance.
I built a health dashboard for one user. I find that interesting not because of what it is, but because of what it suggests about what's coming. The long tail of personal software needs is real, large, and largely unserved. For a long time that was fine because there was no good way to serve it. That excuse is running out.
What happens when "there's no app that does exactly what I need" stops being a dead end is a question I genuinely don't have a clean answer to. But I think it's worth asking.
