Build what you’d use, then doubt what it proves: when every itch can become software
AI makes it easier to turn every idea into software. That makes personal use a better starting point, but a weaker reason to commit.
A year ago, a lot of my small product ideas would have stayed where small ideas usually live: in the back of my head. Maybe as a bulleted idea in my personal Notion if it happened more than a handful of times.
Now many of them become software. It’s not always good, but usually enough to use for at least a few days. I’ve built more prototypes, workflows, GPTs, and small applications in the last year than the rest of my life.
At first, that felt like the end goal itself: more of my ideas could become tangible. I could build directly from the problems I actually understood.
But after a few cycles the excitement wore off and a second pattern became more interesting: most of those things disappeared from my life almost as quickly as they appeared.
Some were useful:
AI-powered voice notes so I could capture five-second ideas while driving.
A reading list and wishlist that combines books, games, TV, and gift ideas.
A few were clever:
An agent that lets me chat with news headlines so I can question the broader picture instead of getting pulled into one article’s bias.
Some were bizarre:
We recently got a Cavapoo puppy. He’s cute, but his poop blends right into the leaf-covered grass in the backyard. I built an app that analyzes a photo and tries to find it.
They were all interesting and most were generally useful. Still, most of them disappeared from my life pretty quickly after I built them. A smaller number of problems kept coming back across all of them: making informational noise useful, decision-making, making learning faster and easier, and using all that to help judgment scale broader than myself.
AI made it easier to explore more directions, but it also made it clearer which questions I could not seem to leave alone.
That has changed how I think about one of startups’ oldest pieces of advice: build something you would use.
For a long time, I’ve liked that advice. It cuts through a lot of product theater. Instead of inventing a persona from a distance, start from a problem you understand. Instead of guessing what people might want, pay attention to something that bothers you enough to fix.
If you build a product you actually use and keep using it after the novelty wears off, that tells you something real: that the problem exists for at least one person and you are close enough to it to appreciate and understand the nuance.
I still think all of that matters. I’m less sure it means what it used to mean.
The old rule worked partly because building was expensive. Not always expensive in money, but expensive in effort, attention, coordination, and skill. If someone spent nights and weekends building a tool for their own problem, the work itself was a filter. It suggested the pain was worth it.
Being able to build anything makes that filter weaker. AI makes it much easier to turn a personal itch into working software, which is mostly good. A lot of useful things should exist that previously would not have been worth the cost. But it changes the signal.
Historically, “I built it because I needed it” carried a lot of information. Today it can also mean “I had an idea and two free hours.” Those are not the same signal.
Imagine someone builds an AI assistant for managing their own product notes. It understands their shorthand, their meeting rhythm, their tolerance for messy drafts, and the way they think about roadmaps. They use it constantly. It saves them time. It feels indispensable. But the fact that it works for them does not prove that another product manager would adopt it. Another person will have different habits, different organization preferences, a different way of using tribal knowledge, and a different need for automation. The builder’s use proves the tool fits one lived system. It does not yet prove the product can survive contact with someone else’s system.
This is where the old advice needs a sharper reading. Personal use is exposure. It is not validation.
When you use your own product, you expose yourself to details that outside observation often misses. You notice whether the flow still makes sense on the fifth use, not just the first. That kind of use is valuable because it improves your judgment about the thing you are making.
But market demand lives one step beyond that. Others have to try it without your enthusiasm or sunk-cost mentality carrying them. They have to use it in ways you didn’t need to. They have to switch from whatever they were doing before. Eventually, they have to pay or risk something meaningful to keep using it.
AI makes this distinction more important because it increases the number of plausible products. When building gets easier, the bottleneck moves.
The hard part becomes less about whether you can make something and more about whether you can tell which things deserve to become products. That puts more pressure on taste, not less.
Taste in product work is not just visual polish or clever interaction design. It is the ability to tell whether a solution fits the shape of the problem and knowing which rough edge matters and which one can wait. It’s being honest when the thing you built is useful to you because of your own habits.
There is a counterargument here: maybe AI makes “build what you’d use” better advice. If more people can create software, then more people can solve real problems from direct experience instead of waiting for a company to notice them. Some of the best products will come from people building directly inside their own pain.
I think that is right. The danger is treating first-person pain as the whole test.
A product can be born from personal need, but it has to grow through other people’s constraints. Otherwise, you are not learning whether there is a market. You are learning that you have good tools for yourself.
That may be the right outcome. One of the underrated effects of AI may be that more software becomes personal, local, and narrow. We may get more tools that are not companies, more workflows that are not platforms, and more products that are valuable without becoming markets. That should change how we talk about building. Not every useful thing needs to become a startup.
But if you are trying to build a product for others, you need a better barometer than love.
The better principle is: explore broadly, commit narrowly.
Use AI to explore more than you could before. Build the weird prototype. Test the workflow. Make the rough version of the thing you would previously have only described. Let yourself create more options, because the falling cost of exploration is one of the most valuable things AI gives us.
Then be much more demanding about what earns commitment.
Would you use it when you are busy, or only when you are curious?
Would someone else use it without you explaining why it matters?
Would they keep using it when it conflicts with their existing habits?
Would they give up something real for it: time, money, workflow, status, control?
Does your own use reveal a broader pattern, or only your personal way of coping?
The first question still matters. If you would not use the thing, that is usually a bad sign. But the next questions are where product work begins. They move you from taste to demand.
I hope AI does not make “build something you’d use” obsolete. I don’t think it will. The principle still protects us from a worse habit: building from abstraction, trend-chasing, and imagined customers. But AI does make the principle easier to misuse. When creation is cheap, conviction can arrive too early. A working prototype can look like evidence before it has earned that role.
So build what you’d use. Love it enough to live with it. Use it long enough to become annoyed by its flaws. Let your own workflow teach you what the product is trying to become.
Then get more skeptical. Your use is the beginning of the evidence, not the end of it.