Case study
Gradia
Student Discounts & Rewards Platform
Role
Scope
Stack
What I built.
- 01
Built and ran the whole platform: the mobile app, the web app and API, the database, access control, scheduled jobs and deployment.
- 02
Students find offers nearby or online, verify with their university email, redeem in store with a code, earn points and climb reward tiers.
- 03
Monthly tier rewards are drawn automatically and designed to stay within UK gambling rules: free to enter, no purchase needed, and points with no cash value.
- 04
Partners onboard their business, create offers, check student codes at the till, confirm online orders and see their performance; commission is collected by Direct Debit.
- 05
The Gradia team approves offers, manages partners, runs rewards and billing, and handles an ambassador programme, with every admin action audited.
- 06
About 15 jobs run automatically every day, week or month, from the reward draw to billing and affiliate purchase syncing.
- 07
Every table has rules for who can see which rows: students see only their own data, partners only their own business.
- 01
Next.js App Router with about 214 API route handlers, the admin and partner dashboards and the public site; a React Native 0.76 app for iOS and Android.
- 02
Supabase Postgres: 183 migrations, about 70 tables, about 234 RLS policies, and column-level grants on top of the row policies.
- 03
In-store redemption with a GPS proximity gate, daily rotating store codes, and a unique index blocking a second redemption per user, offer and day.
- 04
An idempotent points ledger with dedup keys, fail-closed behind .ac.uk verification; monthly draws with a 14-day claim window, redraws and an audit log.
- 05
Commission by category and volume tier, billing periods closed by cron, invoices, and GoCardless Direct Debit with logged webhooks; Awin and CJ affiliate sync every 4 hours.
- 06
15 Vercel cron jobs; CI runs Prettier, lint, typecheck, Vitest and next build, replays every migration to catch schema drift, and fingerprints the production schema daily.
- 07
A written production migration process: commit the SQL, announce it, pre-read, get approval, apply, post-read, merge.