The Quiet Collapse of 'Simple': How a Hit Counter Exposed Infrastructure Fragility

Every founder, every builder, starts with a vision. Sometimes, that vision is grand. Other times, it's as humble as adding a 'billions served' style counter to a new app – that vintage social proof. The story of adding a simple hit counter to a static site on GitHub Pages isn't just a technical anecdote; it’s a masterclass in the invisible forces shaping web development and a sharp reminder that 'simple' often hides layers of complexity you only discover when things silently break.

The interesting thing about this story is not merely that a free API failed and a developer found a workaround. It is actually a raw look into the fragility of relying on non-core infrastructure, the silent gatekeeping power of ad-blockers and DNS filters, and the strategic importance of choosing battle-tested platforms for even the smallest features. This isn't just about code; it's about distribution, resilience, and the real cost of 'free.'

The 'Simple' Illusion: A 90s Counter Meets Modern Web

Our builder, the Plaid Scientist, had a clear goal: show some basic usage numbers for their dailydoodle app – the digital equivalent of a buzzing Akure tech co-working space feeling busy. A static site, no backend of their own. Naturally, the first thought was a free, no-signup counter API like countapi.mileshilliard.com. A single GET request, a quick update to the DOM.

It worked. On desktop, anyway. Instant gratification, the kind that makes you want to shout "na so we go make am!"

The Silent Sabotage: When Features Just Don't Ship

Then came the snag. Switching to mobile, the counter just sat there. Triple dashes. No error. No crash. Just… nothing. The app worked, but the counter, the piece designed to provide that all-important social proof, refused to update. This wasn't a loud, dramatic failure; it was a quiet, insidious one, like a bus driver in Owerri who subtly reroutes without telling anyone, leaving you stuck. The builder even tried a fallback with an <img> tag – a clever trick because some ad blockers treat image requests differently – but that too failed identically.

This identical failure was crucial. It wasn't about the type of request; it was about the destination.

Unmasking the Culprit: Blocklists as Unseen Gatekeepers

The problem wasn't the code; it was the network. Generic-sounding domains often used for tracking or analytics get swept up in blocklists maintained by ad blockers, privacy tools, and even mobile carriers. These aren't just for ads; they filter out domains that sound like they might be doing something nefarious or resource-intensive. countapi.mileshilliard.com became collateral damage.

This is a critical insight for anyone building on the web. Your users might be behind a firewall of privacy preferences you didn't even know existed. Their mobile carrier might be blocking domains you rely on. Your distribution channels are not just app stores or search rankings; they include the invisible filters between your server and your user's browser.

The Strategic Pivot: Trusting the Titans

The fix wasn't about cleverer code; it was about strategic platform choice. Our builder pivoted to Firebase Realtime Database. The reasoning? firebaseio.com is Google infrastructure. Billions of requests flow through it daily; countless mainstream apps depend on it. Blocklists generally leave it alone because breaking Firebase would mean breaking a significant chunk of the internet.

Using Firebase's REST API (in test mode, for public read/write) for a simple, non-sensitive counter was a pragmatic choice. It provided atomic increments (.sv: { 'increment': 1 }), ensuring race conditions wouldn't fudge the numbers even if two users hit refresh simultaneously – a level of robustness far beyond what a simple free API might offer.

This move highlights a core truth: for crucial, even if 'simple,' functionality, sometimes you need to lean on established giants who have already solved the problems of reliability and reach. Their ubiquity becomes their moat, protecting your tiny feature from the whims of blocklists.

---

The Short Answer

Adding a "simple" hit counter to a static site failed on mobile not due to bad code, but because ad-blockers and network-level filters were silently blocking the generic third-party API domain. The solution involved switching to Firebase, whose critical infrastructure domain (firebaseio.com) is typically whitelisted, ensuring broader reach and reliability.

What Is Really Happening

A developer tried to implement a basic social proof mechanism (a hit counter) using a free, no-signup API on a static site. While it worked on desktops, it failed silently on mobile devices, displaying placeholder dashes instead of updated numbers. Debugging revealed the issue wasn't the request type (fetch vs. image tag) but the entire domain of the free API being blocked by privacy tools, ad-blockers, or mobile network filters. The developer then successfully migrated the counter logic to Firebase Realtime Database using its REST API, leveraging Firebase's atomic server-side increment. This worked because Firebase's core domain is rarely blocked due to its widespread use across critical web services.

The Assumption I'd Challenge

The part I would challenge is the default assumption that "free and simple" means "reliable and available." For developers in Gbagada working with tight budgets and Sapa realities, free tools are often the first choice. But this case perfectly illustrates that 'free' isn't just about monetary cost; it carries hidden costs in terms of reliability, debugging time, and unpredictable distribution issues. You may be optimizing for the wrong metric initially, focusing only on ease of implementation without considering the fragility of the underlying infrastructure.

The Strategic Options

1. Accept the fragility: Continue using independent, free APIs, accepting that some percentage of users will not see the feature due to blocklists. This is acceptable for truly non-critical features, but risky for anything that impacts user experience or core metrics.
2. Self-host a minimal backend: For greater control, spin up a tiny serverless function (e.g., AWS Lambda, Cloudflare Workers) to handle the counter. This adds operational overhead and cost but gives full control over the domain and logic.
3. Leverage platform giants (like Firebase/AWS): Utilize services from major cloud providers. While they might involve more setup initially, their domains are generally whitelisted, offering superior reliability and reach, even for basic features.
4. Client-side only "fake" counter: Implement a counter that simulates incrementing but doesn't actually persist globally. Useful for immediate psychological effect, but not true social proof.
   

My Recommendation

For any feature, no matter how "simple," that you genuinely need users to see and rely on, always lean on robust, widely trusted infrastructure. This means services from major cloud providers (Firebase, AWS, GCP, Azure, Cloudflare) rather than niche free APIs whose domains are easily caught in filter nets. The slight increase in initial setup or marginal cost is a worthwhile investment in reliability and reach. This isn't just about preventing bugs; it's about ensuring your product's features actually distribute to your users.

What I Would Do Next

I would implement a small monitoring system (even a simple cron job hitting the endpoint) to verify the counter's functionality from different network environments (e.g., using a VPN from different locations, or testing on various mobile networks). This isn't just for counters; it's a general principle. For anything critical, you must actively monitor reachability, not just uptime. I'd also document the specific reasons for choosing Firebase (blocklist resilience, atomicity) to inform future technical decisions for the team. This "no gree for anybody" approach to verification ensures silent failures don't become silent killers for critical features.

What Would Change My Mind

If robust, publicly audited, and widely whitelisted free APIs emerged that explicitly guaranteed their domains would not be blocklisted by major ad-blockers and privacy tools, and could demonstrate this with public data on reachability across diverse network environments, I might reconsider for truly low-stakes features. However, the economic incentive for such an API to remain "free" while maintaining this level of resilience is low. Until then, the strategic advantage of relying on the internet's core infrastructure (Firebase, Cloudflare, etc.) for distributed reliability remains too strong to ignore.