Zums

The problem

Reward apps live or die on whether people believe they will actually get paid. The user side has to make it obvious what a task is worth and where their balance stands; the operator side has to verify a task was really completed before any money moves. Get either half wrong and the app is either a scam to its users or a leak to whoever is funding it.

What I built

• The mobile app end to end: accounts, the earning surface, the survey and challenge flow, a social layer, and a profile that carries the progression.
• A level progression tied to completed activity, so the app has a reason to open beyond the next payout.
• The operator dashboard: quests, survey providers, users, payouts with per-payout detail, a transaction ledger, analytics and user feedback.
• The payout pipeline connecting the two — completion on one side, verification and money out on the other.

Decisions worth defending

• Operator tooling is a separate app, not admin screens hidden inside the product. The people running campaigns can work without shipping an app release, and the user-facing app stays free of code that only staff should ever reach.
• Survey providers are a first-class entity rather than one hardcoded integration. Adding a new source of tasks is configuration, not a rewrite — which matters because provider availability is the thing most outside your control.
• Payouts and transactions are separate records. A payout is a decision, a transaction is money actually moving; collapsing them into one row makes reconciliation impossible the first time something fails halfway.