Joygiver
One link. Everyone chips in.

- Lead engineer
- 2026
- Django · PostgreSQL · Expo · Next.js · Paystack · Cloudflare Workers
- backend tests
- 3,000+backend tests
- pixel-baseline screens
- 218pixel-baseline screens
- payment to screen
- ~20 mspayment to screen
The problem
A birthday, a wedding or a trad in Nigeria means a flood of transfers to one account number, and nobody knowing what anyone actually wanted. Gifting is generous and completely unstructured.
The approach
One list, one link. Friends chip in any amount, gift a whole item, or fund a cash goal, straight from the link, with no account needed.
- The app. iOS and Android, with widgets and Live Activities, so a gift lands on the owner's lock screen.
- Guest pages. Checkout, receipts, claims and group joins on the web.
- joygiver ops. The internal console for money, trust, the shop and support.
- The shop. Items from our own wholesalers, with the margin set per product.
Money is the hard part. Every naira lives in a double-entry ledger, in kobo. Audit entries are append-only, enforced by a Postgres trigger, not by convention. Every money request carries an idempotency key. A secret giver is hidden from the list owner and guests, never from the ledger. Payouts above ₦500k need two approvers, and never the same person twice.
What I owned
The platform, end to end. Django 5.2 and DRF on ASGI, PostgreSQL, two Redis instances with different eviction policies, Celery on three queues, and websockets for realtime. Paystack, KYC, SMS and push each sit behind a provider interface with a deterministic fake for tests, and production refuses to boot with a fake. Expo for the app, Next.js on Cloudflare Workers for the web, Heroku for the API. 218 screenshot baselines hold every screen to the design.
Outcome
Version 1.0 submitted to the App Store in October 2026. The campus-by-campus beta is open at joygiver.app. A payment reaches the list owner's screen in about 20 ms.