We built an entire points-and-badges system the app never once called

During a recent Hook Audit for ChurchWork, a church member-engagement product, we discovered a fully built and mounted gamification system with points, badges, levels, and a leaderboard that was entirely unused. The mobile app, which members interact with, never called a single one of these backend endpoints, meaning the elaborate reward system never reached its intended users.

The Unseen Gamification System

The backend of ChurchWork contained a sophisticated system designed to incentivize member engagement. Points were meticulously calculated for various actions: attending services, making donations, and even bringing new visitors. Badges were designed to commemorate milestones, and a leaderboard tracked member progress, presumably to foster friendly competition and recognition within the community. From a technical standpoint, the feature "existed" in the codebase. All the logic was there, ready to process and display.

The striking part was the complete disconnect between this reliable backend infrastructure and the user-facing mobile application. Not a single line of code in the app was found to initiate a call to these gamification endpoints. Members using the app, who might have been motivated by these rewards, had no indication they even existed. The points they earned, the badges they qualified for, and their standing on any leaderboard were entirely invisible. They simply weren't presented. This highlights a critical lesson in product development and auditing: a feature's existence in the backend does not equate to its presence or utility for the user. It also speaks to the challenges of feature creep or a misalignment between development efforts and actual user experience implementation.

The Problem of Unused Rewards

Nir Eyal's "Hooked" methodology emphasizes the power of variable rewards in driving user engagement. A core principle is that unpredictable, yet desirable, rewards create a powerful loop that keeps users coming back. However, for a reward system to work, it must actually reach the user. A reward system that exists only in code, never surfaced to the user, is not a weak reward; it is no reward at all.

In the case of ChurchWork, the team put in the effort to define what actions would earn points (attendance, giving, invitations), what those points would unlock (badges, levels), and how progress would be displayed (leaderboard). They built the entire mechanism, but crucially, they never wired the one thread that would allow a single member to ever see or interact with any of it. This points to a fundamental breakdown in the product development pipeline, where a significant feature was built without ensuring its complete integration into the user experience, well beyond a missed opportunity for engagement.

Why Auditing User-Facing Code Matters

This finding from the Hook Audit serves as the clearest possible illustration of why a thorough product audit needs to read the client code a user actually experiences, not just verify whether a feature "exists" somewhere in the broader codebase. Relying solely on a list of backend features, or even database schema, can lead to a dangerously incomplete picture of what users are actually getting.

An effective audit must trace the user's journey from their first interaction with the interface all the way through to how backend data is presented to them. It must ask:

• What does the user see?
• What actions can the user take?
• What feedback does the user receive?

Without scrutinizing the user-facing application, one could easily conclude that ChurchWork had a "gamification system" in place. Yet, for the actual members, that system was functionally absent. This experience underscores why an approval gate for any new feature, similar to how Why AI-written marketing content still needs a human approval gate discusses content, is critical. It prevents the deployment of "ghost features" that consume development resources but deliver no user value. For solo founders and small teams, understanding these hidden gaps is crucial for efficient resource allocation and ensuring every feature built genuinely contributes to the user experience and product goals.