Four types of products worth building when anyone can code
I've been thinking about my first product—something for someone else in the world, not for myself—for over a month now.
We live in an era where you can build a product in days. But being able to build fast and making something people actually keep using are completely different problems.
· Figuring out what to build, who for, and why: about 80%
· Actually implementing it: 5-10% (sometimes 1%)
· Tuning the business model, policies, and technology based on customer feedback and market shifts: the rest
Since anyone can build an app, the market is oversupplied. Plenty of startups that got YC funding disappear or pivot over time. Users are getting pickier. If they don't feel value on first use, they delete immediately. There's no shortage of alternatives.
I opened my smartphone and looked around.
Products that survive fall into roughly four categories. A single product can belong to multiple types at once.
1. Asset Lock-In
Gallery, Drive, SNS—the kind where user data, connections, and records accumulate, making it harder to leave. The switching cost goes up, but you need high trust, stability, and security from the start. This is the hardest area for solo founders or early-stage startups to enter.
2. Content is Key
YouTube, Netflix, Amazon, Yes24—users open the app to discover and consume content. The winning factor is the ability to sustain a massive amount of quality content. Teams with weak capital struggle to compete head-on. That said, if you narrow the scope to a specific genre, profession, or taste, there's a chance to build a small but strong market.
3. Unique Workflow
A product that solves a specific, recurring need—or a once-in-a-lifetime necessity—dramatically better than existing methods. Don't forget: it's not just about solving the problem, but delivering overwhelmingly superior experience in that workflow.
You need to find needs that big companies ignore because the market seems small, or needs that are desperate to specific customers but unknown to the general public—all within your area of interest. There has to be a concrete reason why users save time, money, or stress compared to existing methods. And you need a distribution channel to actually deliver that value.
In this space, discovering people who've been putting up with inconvenience is a more realistic starting point than creating a new market. At the same time, it connects to predicting workflows that will emerge in the future.
When technology, systems, labor methods, and consumption habits change, new tasks and inconveniences emerge that didn't exist before. For example, the spread of generative AI, remote collaboration, aging populations, regulatory changes, and the rise of individual creators—these shifts in the world can create new problems. In short: anticipate new workflows created by world change, then target a small but clear audience first.
Over time, demand in this space can grow, and big companies might follow or absorb it as a platform feature. That's why you need to design for context data accumulation or customer asset structures from the early stage—to maintain a moat.
4. General-Purpose Tools (Productivity/Support)
Notes, voice recording, calendar, journaling. Useful in certain workflows but not critical to lose. Over the past 20 years, countless attempts have been made. The risk of becoming obsolete overnight from a single big tech update is greatest here.
But there's still a path. Don't stay broad like "note app"—if you build a tool tailored deeply to a specific profession, situation, or workflow, you can evolve from category 4 beyond its limits into category 3. For example, the moment you shift from a simple notepad to "a checklist tool for real estate contracts" or "a settlement tool for IT freelancers," the replaceability drops.
These four categories aren't completely separate—they overlap. A tool can create asset lock-in, and content can become a unique service itself. So what matters more than the classification is seeing clearly what kind of stickiness will keep what I'm building alive.
When making a product, the important question isn't "what can I build?" It's closer to this:
- Whose problem is it?
- How often does this problem occur?
- How do they solve it now?
- Why isn't the existing approach enough?
- What do users lose if this product disappears?
- Where do users discover this product, why do they trust it, and how do they keep using it?
- Who will pay?
Especially for small teams or solo founders, rather than competing in a huge market against everyone, you should find a customer group where the problem is clear and alternatives are weak—even if it's small. Starting with the idea of creating a big market from day one might be less realistic than solving one specific person's specific problem very well.
The faster we can build, the more important the time to decide what to build has actually become.
Good products don't have to be complex or massive. If it's urgent enough for someone, clearly better than existing methods, and has reasons to be used repeatedly, you can start small. The problem isn't building the product. It's pinpointing exactly what problem will keep getting used.