The tool you built for yourself is not a product
A useful internal tool has a specific, seductive property: it already has one happy user — you. That single data point gets mistaken for market validation far more often than it should, and the resulting products are some of the least successful a portfolio operator ever ships.
The one-customer trap
Building a tool to solve your own recurring problem is one of the healthiest instincts an operator can have — it is efficient, it is grounded in a real need, and it usually gets built faster than anything commissioned for an external customer, because the requirements are already fully understood by the only person who has to approve them. The trouble starts the moment that efficiency gets mistaken for market signal.
A tool solving your own problem has exactly one validated customer: you. That is real validation, but it is validation of a sample size of one, and the temptation to extrapolate from that one data point to an entire addressable market is exactly the failure mode that turns a genuinely useful internal tool into a poorly performing external product.
Why the extrapolation feels safer than it is
It feels like sound reasoning: if this problem is annoying enough that I built a whole tool to solve it, surely other people in a similar situation feel the same annoyance. The reasoning fails because your situation is rarely as representative as it feels from the inside. You have a specific combination of other tools, workflows, and context that shapes exactly how the problem shows up for you — a combination that is not automatically shared by anyone else, including people who nominally do similar work.
This is compounded by a second bias: you built the tool, so you already understand it deeply and find it easy to use. A stranger encountering the same tool for the first time experiences none of that built-in familiarity, and the gap between how easy the tool feels to its creator and how easy it feels to an actual new user is one of the most consistently underestimated distances in product development.
- Before productizing, find at least a handful of strangers with the same problem, independently of you
- Ask whether they currently pay for anything to solve this problem, even a bad solution — no existing spend is a warning sign
- Watch someone unfamiliar use the tool without your guidance and note where they get stuck
- Separate "I find this useful" from "I would be upset if this were taken away," which is a stronger signal
- Resist building more features for a market of one before external validation exists
When it does generalize
The internal tools that genuinely do become good products share a specific trait: the problem they solve is common to a role or workflow, not to your particular idiosyncratic setup. A tool built to manage recurring content across several properties you personally own is unlikely to generalize, because almost nobody else runs several properties in exactly your configuration. A tool built to solve a genuinely common workflow annoyance — one shared by anyone doing a certain kind of work, regardless of their specific setup — has a real shot.
The distinction is subtle but decisive: solving your problem is not the achievement. Recognizing that your problem happens to be a common one, rather than a specific one, is the actual insight, and it requires deliberately looking outward rather than trusting the internal signal that the tool feels valuable to you.
The healthier default
Given the base rate, the healthier default for an operator running a portfolio of small internet businesses is to build internal tools freely, expect most of them to stay internal forever, and treat productization as a rare, deliberate decision requiring real external evidence — not the natural next step for anything that works well enough to keep using yourself.
This reframing removes a specific kind of disappointment: an internal tool that never becomes a product has not failed. It did exactly the job it was built for, which was saving you time on a problem you actually had. The failure only happens when that quiet, genuine success gets misread as evidence of a market that was never actually tested.
Common questions
Are there internal tools that genuinely do make good products?
Occasionally, but almost always because the underlying problem turns out to be common far beyond the operator's own specific situation, not because the tool happened to be convenient to build. The test is whether strangers with a genuinely different context still recognize the exact problem, not whether they find the tool interesting.
How do you tell the difference between a real opportunity and self-validation?
By finding out whether people who are not you, who have no relationship with you, will pay before you build anything more than a rough version. A tool that only ever gets validated by people who already like you has not been validated at all.
Is it wasteful to build internal tools that will never become products?
No — the waste is in expecting them to become products in the first place. A tool that only ever saves you time internally has already paid for itself many times over if it works well, regardless of whether it ever generates a dollar of external revenue.
Every property in the Don Gastón portfolio is independently live — built, deployed, and operated by one person.
See what's live in the portfolio