Part 7, The Small Problems You Don’t Plan For

One funny thing about building a tiny site like Rankiwiki:
you end up solving problems you never planned to have.
Last week, I spent almost the entire time fixing… profanity.
Not marketing.
Not growth.
Not UI polish.
Just figuring out how to properly block swear words across search, comments, and front-end post submissions.
And somehow, that turned into building an entire WordPress plugin.
It wasn’t on any roadmap, I don’t even have a roadmap.
But this is what early-stage building is really like:
you don’t choose the problems; the problems choose you.

1. The original hack stopped working
   Rankiwiki had one tiny snippet inside functions.php:
   If a search query included a bad word → force a 404
   Hard-coded English swear words
   No feedback, no language detection, no consistency
   It “worked” until it didn’t.
   Comments with profanity were still allowed.
   Posts had no filtering.
   And users just saw a 404, which made Rankiwiki look broken.
   Small detail, but it quietly ruined the experience.

2. So the “simple idea” became a plugin
   I ended up building a full plugin:
   RW_Profanity_Filter
   multilingual word lists
   search/comment/post filtering
   custom error messages
   toast notifications
   masked profanity display
   centralized settings page
   It was supposed to take an hour.
   It took days.
   And yet this is exactly what makes early building interesting:
   tiny features accidentally become entire systems.

3. The surprising part
   Rankiwiki still gets maybe 10 visitors a day.
   There’s no revenue.
   No hype cycle.
   No real marketing push yet.
   But I’ve started to understand something:
   Even when the traffic is tiny, the product deserves to behave like a real product.
   If someone types a Korean or Russian swear word and the message returns in their language,
   that feels like a detail from a much bigger, much more mature platform.
   Even if only 2 people experience it,
   it still raises the quality bar for the next 200… or 2,000.

4. Why this matters for builders
   I used to think the early challenge was “getting users.”
   But now I’m seeing another layer:
   making the product trustworthy, even when nobody is watching.
   In the early days, one confusing message or broken interaction can lose the only visitor you had that day.
   So the small problems do matter.
   Sometimes more than the big ones.

If you’re curious how Rankiwiki feels today, here’s the link:
https://rankiwiki.com
Thanks for following the journey, even during the quiet parts.