Every year, a friend group I know plays 'Secret Santa'. And every year, a slight problem (?) occurs: couples draw each other. It is absolutely not the end of the world, of course. But, you have to admit it may defeat the point. You're likely already buying your partner a gift for the holidays. The whole idea is to create connections across the group — not to formalize what you were likely doing anyway.
So, groups re-draw. Or someone would swap quietly. Or we'd just live with it. A minor annoyance, never quite solved.
This year, I decided to (quite pedantically, I might add) look for an app that handles it. Surely someone has built this? Partner exclusions seem like an obvious feature.
Turns out: not really? What I found was either too simple (no exclusion logic) or too bloated (account creation, email verification, features I didn't need). I just wanted to add names, mark who is partnered with whom, and have the system figure out valid assignments.
And then a thought: this shouldn't be that hard...right?
The Experiment
I'm not a technical person by training. I do not have a CS background. The last time I did anything remotely related to programming was sophomore year of college. But I have been curious about what's possible when you collaborate with AI tools to build things — not as a developer, but as someone with an idea and a willingness to figure it out.
So, I tried. Not with any grand ambition, mind you. Just a simple: can I make this work?
I opened up Claude and described what I wanted. A simple app where an organizer adds participants, marks partners, and the system assigns names without anyone drawing their partner. And, of course, a way to share this app so everyone can make their own draws on their personal devices. That's it.
And it did that. The first version did one thing: generate valid assignments. Add names, mark partners, hit a button, get a match. No self-draws, no partner draws. Done.
It worked. And then I kept using it. And that's when the questions started.
Building by Asking Questions
What stops someone from clicking another person's name and seeing their assignment?
Nothing. If someone curious (or just mischievous, if we're honest), wanted to pretend to be someone else and see their assignment, it was easy. The app had no protection. So, I added PINs — each person creates a 4-digit code when they first select their name. Simple, not bulletproof, but enough to keep honest people honest.
How will people know whether their gift ideas will actually be worth it?
The assignment tells you who you're shopping for, but not what they want. So, I added wishlists. Everyone adds a few gift ideas. Visible to the whole group.
What if you have a question for your giftee but don't want to reveal yourself?
That's where anonymous messaging came in. Gift-givers can send questions ("Do you prefer dark or milk chocolate?") without exposing who's asking. Recipients can reply without knowing who they're talking to.
Each feature came from the same pattern: use the app, notice a gap, build the fix. None of this was in the original plan. It emerged from experimentation — from just asking question after question by putting myself in the user's shoes.
The Moment It Worked
Once the core pieces were in place, I tested end-to-end. Added names. Marked partners. Generated assignments. Set a PIN. Revealed a match. Tried to access someone else's assignment — blocked. Added wishlist items. Sent an anonymous question.
I had my parents try it next — my usual first testers. They added their names, set PINs, revealed their assignments. My mom's reaction: "Wow, this is actually nice."
That was the moment. I had...built something? It felt good.
What This Project Taught Me
Products emerge from real-world use, not from specs.
I didn't plan the PIN system, the wishlists, or the anonymous messaging upfront. Each one came from using the app and noticing what was missing. That's a different way of building than I was used to — where you define requirements, then execute. Here, the requirements revealed themselves through experimentation.
That's a muscle I want to keep developing: building something small, using it, and letting the gaps tell you what to build next.
Edge cases force real thinking.
The partner exclusion logic sounds simple: don't let couples draw each other. But when you actually build it, you have to think harder. What if there are multiple couples? What if the constraints make a valid assignment impossible? What if someone's added without a partner — do they have any restrictions?
And then there was the PIN feature — which wasn't even in my original plan. It only emerged when I asked: how would someone cheat? That question revealed a gap I'd completely missed. The feature came from thinking through use, not from a spec.
These edge cases forced me to think precisely, not just directionally. The details matter because the system has to actually run as intended.
I wanted to get fluent in this.
This was the real takeaway. Not "I built an app" — but "I want to keep doing this."
There's something deeply satisfying about going from just an idea to a working thing. About describing what you want, wrestling with the details, and ending up with something real. Something people use.
I didn't know if I could do this before I tried. Now I know I can — and I want to get better at it. That decision — to treat this as a skill worth developing — came from this project.
What's Next
The app is live. My friend group used it. It did what it needed to do.
Could I add features? Sure. Email reminders. A "gift purchased" checkbox. Better mobile styling. But honestly, it works. And that was the goal.
What came next was more building. More projects. A private social app for small groups. A newsletter aggregator. A voice capture tool. Each one a little more complex, a little more technically interesting.
But this is where it started. A small annoyance, a simple question — can I build this? — and the discovery that the answer was yes.