Build a product for your own problem when you are a representative user of a problem that recurs, and do not when your situation is unusual. Being the user removes the translation layer between the problem and the person solving it, you already know which features are theatre and what "finished" feels like. What it does not tell you is whether anyone else has the problem badly enough to pay, and that is the question that decides the outcome.
Ross Jones, Founder, The Hopium Lab. Last modified 22 July 2026.
Five of the products in this portfolio started as personal annoyances. This is what that method is genuinely good at, and where it quietly fails.
What does being your own user actually give you?
Being the user gives you information, not motivation, and the information is the part that matters.
When you are the user you know exactly where the friction is, which workflow is the real one rather than the one people describe in interviews, and what a good outcome feels like in your hands. There is no research to misread, no persona to invent, no gap between what someone said in a call and what they do on a Tuesday. You skip the translation layer that ruins most products, where a real problem gets described to someone who has never had it and comes back as a feature that misses.
It also gives you a brutally honest tester who is available at 2am and cannot be fobbed off with a roadmap.
The first user is you: free, permanently available, and completely unable to be impressed by a demo.
What did that produce here?
Five products, each of which began as something that annoyed me on a specific afternoon.
| Product | The annoyance | The recurring cost it removed |
|---|---|---|
| MONII | Checking a deploy meant tab-hopping between two dashboards | Context-switching, several times a day |
| Owndle | Domains scattered across registrars; renewals discovered when something broke | Silent expiry risk |
| TKN | No visibility of LLM spend across providers until the bill arrived | Unbounded cost exposure |
| FRGMNT | "What is our real MRR?" had five different answers | Reconciliation, monthly, by hand |
| RoamRate | Currency conversion that fails exactly when there is no signal | A small, frequent, avoidable friction |
None of these came from a market-sizing exercise. Every one came from a Tuesday. And each shipped with an MCP server and a CLI, because the thing increasingly using them is an agent rather than a pair of hands.
What does being your own user hide?
It hides whether your problem is common, and that omission kills more of these products than any technical failure.
You are one data point, and you are the least objective one available. The frictions you notice are shaped by your stack, your scale, your tolerance and your habits. A person running two dozen products has deploy and cost problems that a person running one simply does not have, so a tool built for the first person can be perfectly good and still have almost no market.
Three specific blind spots follow. Frequency: your problem may be acute for you and annual for everyone else, and annual problems do not sustain subscriptions. Willingness to pay: you would have paid anything at the moment of maximum irritation, which tells you nothing about a calm buyer. And the workaround: most people have already half-solved it with a spreadsheet they do not resent, which is a far higher bar than "no solution exists".
Scratching your own itch tells you the problem is real. It tells you nothing about whether it is common, frequent, or worth money to anyone else.
How do you tell a product from a preference?
You test whether the problem exists at other people's scale, in other people's stacks, without you explaining it.
The signal to look for is whether someone describes your problem back to you before you have named it. If explaining the product requires establishing the problem first, the problem is not widely felt, and that is a marketing cost you will pay forever. Conversely, if people finish your sentence, the itch is shared.
The cheapest test is to ship the smallest honest version and watch what people do with it rather than what they say. Enthusiasm is free; usage is not. And a tool that solves a real recurring problem gets used on the days when nobody is feeling generous about it.
What are the named failure modes?
Four, and each one has a recognisable smell.
The audience of one. Built beautifully, solves your exact configuration, and has no natural second user. Detectable early: you cannot name three people with the same problem who are not you.
The problem that was actually a preference. You did not like the existing tool. That is not the same as it being wrong, and "I would design it differently" is not a business.
The workaround you underestimated. Everyone else already has a spreadsheet, a shell script, or a habit. Beating "nothing" is easy; beating "a thing that works and is already paid for" is not.
The maintenance you did not price. A tool you built for yourself has one demanding user. The moment it has others, it acquires support, compatibility and uptime obligations that continue long after the original itch stopped itching.
When should you not build it?
Do not build it when your situation is unusual, when the problem is rare, or when a good tool already exists and you simply want a different one.
Unusual is the important word. If the reason you have this problem is a choice almost nobody else makes, an idiosyncratic stack, an unusual scale, a workflow you invented, then you are not a representative user, you are an outlier, and building for an outlier produces a tool with an audience of one. That is a completely legitimate thing to build. Just build it as a script and stop, rather than as a product with a landing page.
Also skip it where the incumbent is genuinely good and your objection is aesthetic. Rebuilding a solved problem because you would have made different choices is the most expensive way to express taste.
How do you decide?
Run the problem through five questions before writing anything.
IS THIS A PRODUCT OR A TUESDAY?
The Hopium Lab · v1.0 · 22 July 2026 · take it, fork it, argue with it
1. FREQUENCY
[ ] How often does this actually bite? Daily, weekly, or once a quarter?
[ ] Quarterly problems do not sustain subscriptions
2. REPRESENTATIVENESS
[ ] Name three people with this problem who are not you
[ ] Is the cause of your problem a choice almost nobody else makes?
3. THE INCUMBENT WORKAROUND
[ ] What are they doing today instead? "Nothing" is rare and suspicious
[ ] Does your version beat a spreadsheet they already tolerate?
4. RECOGNITION
[ ] Do people describe the problem back before you name it?
[ ] If you must explain the problem first, that is a permanent marketing cost
5. THE MAINTENANCE PRICE
[ ] Are you willing to support this in three years, on a bad week?
[ ] If not, ship it as a script and be honest that it is a script
THE TEST: if you fixed your own problem and shipped nothing, would you still
be glad you built it? If yes, build it. If no, you wanted a business, and
that needs the questions above answered first.
The last test is the useful one. The failure mode of this method is not building the wrong tool, it is building the right tool for one person and then feeling betrayed that nobody else showed up.
Ross Jones, Founder, The Hopium Lab. Last modified 22 July 2026.