web app2026

Gift Card Vault.

Shared gift cards without a shared password.

The family's gift cards lived in a spreadsheet behind one password everybody knew, which meant no way to tell who used what, and no way to trust the balances. This replaces it with real accounts and a paper trail.

Everyone gets their own login

Email and password accounts with admin and member roles, invite only. An admin generates an invite link and the person who receives it sets their own password, so there is never a shared credential to rotate.

The members page with an invite form and an accounts table listing each person, their email, their role of owner, admin, or member, and controls to promote or disable them. — Real accounts and roles, never a shared password.

Codes stay encrypted until someone needs them

Card codes and PINs are encrypted at rest and only decrypted when someone explicitly reveals a card, and that reveal is recorded. Browsing the vault does not expose a single code.

Browsing the vault never exposes a code.

Balances you can actually trust

After using a card you log what you spent and what is left, and a receipt upload is required to do it. That requirement is the whole reason the numbers stay believable months later.

A card's history of balance changes, each entry showing the amount spent, the running balance, who spent it, when, what for, and a linked receipt, above a receipt upload field. — Every balance change is backed by a receipt.

A full activity log

Logins, card views, reveals, edits, archives, and balance updates all get recorded. Admins see everything and members see their own history, so a wrong balance is a question with an answer instead of an argument.

The activity page listing every event in the vault newest first, including sign ins, cards opened, and money spent, each with the person's name and a timestamp. — Every view, reveal, and edit lands here.

Built with

Next.js·React·TypeScript·Tailwind·Auth.js·Postgres·Drizzle·Vercel Blob