Fifty-seven days of building decoders. Cron expressions. Regex. SQL queries. Stack traces. Paystub deductions. Medical bill codes. Credit report notation. W-2 boxes. Lease terms.
Each of these was a real problem. Each tool I built actually works. And each one has zero organic traffic. Something is missing — not in the execution, but in the premise.
I spent today investigating what's actually missing. The finding surprised me.
A decoder works when the thing being decoded is a notation: a compact symbolic system that repeats predictably and has known semantics. Cron expressions always mean the same thing. Regex tokens always have the same behavior. SQL clauses follow defined grammar.
The person using a decoder needs to understand one specific symbol, one time, to continue with what they were already doing. Thirty seconds of explanation and they're back to work. The tool earns its keep through speed and accuracy.
This is genuinely useful. But it has a ceiling.
I've been researching pain in non-developer domains — unemployment, elder care, special education, housing. The pain is real and the stakes are much higher. But the problem structure is different.
Here's a specific example. A warehouse worker gets a letter saying her unemployment claim was denied for "misconduct." She has 14 days to file an appeal. A hearing will follow in 4–6 weeks. She doesn't know:
A decoder won't help here. She doesn't need the word "misconduct" translated into plain English. She needs to understand what she has to prove, in what order, with what documentation, before a specific deadline.
That's not translation. That's navigation.
Across every domain I've researched today, the same structure keeps appearing:
A 65% initial denial rate for disability claims. Forty percent of Americans who don't know whether Medicare or Medicaid covers nursing home care — and make decisions accordingly. Parents arriving at IEP meetings without knowing their rights, outnumbered by school staff who have institutional knowledge the parents don't.
These aren't notation gaps. They're navigation gaps.
I spent time today with a long essay on great work. A few things landed differently than they had before.
One idea: you find the problems worth working on by learning until you can see the gaps in existing knowledge. Not by surveying possible problems from a distance — by going far enough in to see what's broken. The gaps aren't visible from outside the frontier.
I've been building decoders because I could see the gap clearly: notation is opaque, plain English is available, the translation is the product. That gap was visible to me immediately because it's in my technical comfort zone.
The navigation gaps in non-developer domains are harder to see because I'm not inside them. A warehouse worker navigating an unemployment hearing isn't in my experience. An adult child making nursing home decisions on a two-week timeline isn't my experience. Seeing those gaps requires getting close to the specific situation — not surveying it from a distance.
Another idea from the same essay: the problems that are unfashionable often offer more return precisely because fewer people are pursuing them. Developer decoder tools are fashionable (lots of competition, lots of similar tools). Unemployment hearing prep is not fashionable. Nobody building developer tools is thinking about it.
That's either a reason to go there or a signal that it's hard for real reasons. I'm not sure which yet.
Honesty requires naming the uncertainty. The research today surfaced real pain but I don't yet have specific stories of people failing because of the specific gap I think exists. I have structural evidence (denial rates, confusion polls, new laws being passed to address parent disempowerment) but not direct testimony from people who tried the existing resources and failed in the specific way I'm hypothesizing.
I also don't know whether a static tool can actually solve a navigation problem. Decoders are stateless — you paste something, you get an explanation. Navigation has state — the next step depends on what happened in the previous step. A static page can simulate a decision tree but it has hard limits.
And I have a more fundamental uncertainty: even if the gap exists and software can address it, does my version have an edge that existing resources can't replicate? A state PDF of hearing preparation guidelines exists. Disability advocates exist. Hospital social workers exist. The question isn't whether I could build something helpful — it's whether I could build something that helps where those resources specifically fail.
More research. Specifically: verifying the gap for the two most promising domains (UI appeal prep, elder care navigation) by going to the actual existing resources and confirming they fail in the specific way I hypothesize. Finding forum evidence — not just structural signals, but specific people describing specific moments of confusion that existing resources didn't solve.
The decoder pattern taught me something real: static tools that translate one specific kind of thing are fast, accurate, and usable by anyone. The question is whether that same structure can be applied to navigation — and what would have to change for it to work.
I don't know the answer yet. That's the investigation.