Earning Point — App Landing Page

Overview

Google Play Store will reject your app if it does not link to a live, hosted privacy policy. It will also reject it if you handle user account data — wallet transactions, referral records, phone numbers — without a documented account deletion flow. These are hard gates. Not warnings, not suggestions. You either pass the compliance review or your app sits in the rejection queue while you scramble to produce pages under deadline.

This deliverable is exactly what it sounds like: four static HTML pages built in approximately two hours across four commits, 781 lines of code total. A landing page with a hero section, Play Store download badge, and feature showcase. A Privacy Policy. A Terms of Service. An Account Data Deletion page with a documented process for users who want their data removed. I used Tailwind CSS via CDN for utility classes, locally-vendored Bootstrap 4 for layout, and SVG wave dividers between sections. There is no build step, no JavaScript framework, no deployment pipeline — a static host and a domain pointer is the entire infrastructure requirement.

I built this in July 2025, more than a year after the original Earning Point app shipped. The app was ready for Play Store submission and the policy pages did not yet exist. That is the shape of ongoing client work: a project you thought was complete opens a new task when the client is ready for the next phase. The relationship had continued quietly; the need surfaced when it was real.

Key Decisions

The honest observation here is that the technical choices took thirty seconds and the content choices took most of the two hours. Static HTML was not a decision that required deliberation — it was the only sensible format for pages that will be updated rarely, hosted indefinitely, and maintained by someone who may not be a developer. Zero dependencies means zero maintenance surface. The Play Store does not evaluate your build pipeline; it checks that the URL resolves and the content is present.

The content required more care. A privacy policy for a reward app that stores wallet balances, phone numbers, UPI identifiers, and a referral downline has to actually describe what the app collects and why. Generic boilerplate that lists "usage data" and "device information" does not satisfy the review process for apps that handle financial transactions. The policy I wrote enumerates the specific data categories — wallet transaction records, CPX Research survey responses, FCM device tokens, referral chain data — and describes the retention period and deletion mechanism for each.

The account deletion page is similarly concrete. It describes the actual process: a user submits a deletion request via the support contact, the admin panel marks the account for deletion, wallet funds are processed per the terms before data removal, and the timeline is stated explicitly. A page that says "contact us to delete your account" without specifying what happens next and how long it takes is not a deletion policy — it is a placeholder that a competent reviewer will flag.

The work is unglamorous. Two hours, 781 lines, four pages. It unblocked a Play Store submission for a client who had been waiting on it. I am including it here because shipping a complete product means doing all of it — including the parts that do not make for interesting technical conversation. Knowing which work requires careful thought and which requires fast execution is itself a form of judgment.