Magpi began as a small idea: a simple wishlist tool that didn’t depend on social graphs, tracking pixels, or data-hungry onboarding flows. What it became was a full-stack application that helped me deepen my technical practice while exploring what “privacy by default” actually looks like in a modern consumer product.

Designing the Core Experience

At its heart, Magpi lets people create wishlists and share them with friends and family. But the experience is shaped by a few principles:

- users shouldn’t have to create an account to start

- authentication should be simple and secure

- owners shouldn’t see who bought what unless they choose to

- gift-givers shouldn’t accidentally purchase duplicates

- data should only be stored when it needs to be, and never more

Those constraints drove most of the architecture.

Privacy as a Feature, Not an Afterthought

I implemented Supabase Row Level Security (RLS) so users can access only their own data, enforced at the database layer rather than the UI. Addresses are hidden by default and can only be revealed through an explicit opt-in. List owners see “someone claimed this” unless they enable a transparency setting. All behavioral tracking, including click-based “purchase intention” prompts, lives locally on the device, not on the server.

This approach mirrors the way I think about AI safety: meaningful guardrails belong in the foundation, not on the surface.

Most of the app was built using Claude Code CLI, which helped me scaffold components, debug tricky authentication issues, and iterate quickly when dealing with edge cases like race conditions and RLS enforcement.

What I Learned

Magpi strengthened my understanding of dev workflows and the realities of building modern applications — from debugging session propagation to designing share links that don’t expose unnecessary data. It also reinforced a belief I return to often: privacy isn’t a constraint on creativity; it’s part of the craft.