Wishlist: When Tech Fixes a Family Problem

Every year, same story. As soon as the holidays creep up, the family WhatsApp group blows up: "What do you want for Christmas?", "Hold on, I was gonna get them that…", "Didn't you want a sweater? Oh no, that was last year."

Solutions exist out there. Amazon lists, dedicated apps. But each one comes with a catch: signing up on some third-party platform, dealing with ads, relying on a service that could shut down or change its rules overnight. And the real sticking point: how do you reserve a gift quietly without the person seeing it's been taken?

Simple need. Comes back every year. Very concrete. I had the skills. I built it.

Wishlist, designed and shipped end to end. The concept is deliberately straightforward: each family member browses the others' lists and reserves a gift, without the recipient seeing who picked what.

Role management is the engine of the experience: • The visitor browses lists and reserves what they want to give • The admin manages their own list. They add ideas, upload photos, fill in prices and links • The super-admin creates and manages accounts for the entire family

I also slipped in a Christmas theme you can toggle with a single setting. Snowflakes, warm colors. Because the little details that make people smile matter just as much as the features.

Two separate pieces that talk through an API.

The interface: Next.js and React. Animated cards, smooth navigation, real-time form validation, confirmation dialogs on sensitive actions, responsive design. The goal: my mom should find her way around on the first click.

The server: a Python API built with FastAPI. Secure auth, role-based access control, data storage, and a CSV export for admins who want to pull their data out.

The deployment: everything lives inside Docker containers, wired together with Docker Compose, sitting behind a reverse proxy (Traefik + CrowdSec) that handles HTTPS and attack protection. Self-hosted, self-contained, rock-solid.

Shipping an app for your family means getting a beta-testing panel no startup could ever recruit: zero politeness, zero technical background, and a bluntness that no feedback form will ever capture.

Three weeks of use were enough. Three signals. Three iterations.

"I can't log in anymore, your thing says wrong password." Two days after launch, someone was stuck at the login screen with no way back in. I had naively figured that in a small family circle, everyone would remember their credentials. Wrong. I treated it as a UX bug, not a user mistake. Result: a full password reset flow. A "simple" product doesn't get a free pass on covering failure paths.

"But where do we click to see your list?" My first navigation design seemed obvious to me. It wasn't to everyone else. That feedback, delivered bluntly by someone who doesn't overthink things, pushed me to completely rethink the flow for picking lists. Less abstraction, more clarity. What's obvious to the builder is rarely obvious to the user.

"Can I work on my list without everyone seeing it right away?" A use case I hadn't thought of. And yet it made total sense: some people wanted to fill in their list at their own pace before making it public. I added a visibility toggle per list. Simple to code, decisive for adoption.

Three raw, unsolicited pieces of feedback, sometimes sent as voice notes. And each one led to a clear, prioritized, shipped product decision. That's what user-centric really means.