If you missed it, the kickoff post, “Family is the best customer,” sets up HoffStuff and how we got here.

The feature debt got loud.

The first version of HoffStuff was built out of a frustration so blinding that I only considered things 1:1. Meaning:

• One item
• One gifter
• One claim
• No partials
• No co-gifting

Easy enough. But when things started going well, I slowly began to see opportunities for improvement.

The one that finally broke me was when I tried to let users say that they wanted more than one of something. Every backend relation that touched a claim clamored to be rewritten. I made it work in the end, but the frontend wore the compromises:

• Claims that didn’t quite flow smoothly
• Weird display rules in corner cases
• UI that worked but felt like it knew it was lying

In sum: unintuitive…

I was never happy with how all of it landed. I’m still not.

Every item that bubbled up in “Family is the best customer” was a small indicator that I may have to consider a V2 at some point. The “item quantity snafu” was the point where I could no longer deny it. Hoffstuff simply could not continue absorbing everything I wanted to add next.

HoffStuff was a lightweight labor of love that did the job. I didn’t expect the family to run with it the way they did. Every weird-family-edge-case got bolted on as an afterthought, each one welded onto a frame that was never designed to carry it.

Eventually, the seam lines started to show.

The list item shape had grown so many optional fields, resulting in an exponential number of visual permutations. Any non-trivial change broke variations I’d forgotten existed, usually more than one at a time and in ways I couldn’t have imagined.

I knew the design wasn’t right, but changing it without a regression was harder than living with it. We’re talking about rows that were originally only going to show a title, description, and status. Now, we’re juggling 10+ properties that may or may not exist.

There were quieter pieces too.

I didn’t trust changing HoffStuff around live data because someone’s birthday is always on the horizon, and I didn’t want to mess with that. So my maintenance windows got batched into whatever calendar gap I could find between holidays.

Working this way required me to be reactively careful. I dreamed of the day I could be proactively creative without fear.

Because I wasn’t in the codebase daily, picking it up a few weeks later to make a change always meant rediscovering an edge case. By “rediscover,” I mean I shipped a new feature, thinking everything was fine, only to find out from a family member that it was, in fact, not fine.

What happens if a recipient tries to delete an item someone purchased for them in the lead-up to their birthday? Do you:

• Spoil the surprise by telling the recipient and blocking the deletion?
• Silently delete the claim and leave the gifter going, “WTF, where did it go?”

Easy scenario to miss when you’re rushing a change between events.

The shaky foundation kept me from exploring the pile of things I wanted to add…

Item-level and/or logic

I want a PS5, and if I get the PS5, I’d like controllers. Please don’t buy controllers if nobody has claimed the PS5.

I want one of these two sweaters. Please do not buy both.

Co-gifting and partial claims

The bigger rabbit hole quantity opened that I never finished climbing out of.

Somebody wants multiple of something (e.g., three PS5 controllers). Grandma buys one controller, so two remain. How do we show this efficiently without breaking everything when it was meant to be singular?

Restricted-access viewing

In the beginning, everybody could see everything.

What happens when a gifting group needs to bring in people who should be able to claim gifts but shouldn’t see who’s claimed what (think: the awkwardness of recently divorced parents shopping for their children).

How do you introduce granular item/claim visibility across all pages like this without a bunch of weird bugs?

Custom holidays

Hoffstuff was built for birthdays and Christmas, but what about when my niece, Ellie, was graduating from high school, with a slew of going-away-to-college needs?

It doesn’t take much to imagine expanding further into customization, from baby showers to bar mitzvahs. These one-off events shouldn’t mess with the regular cadence of birthdays and holidays.

In the beginning, lists were only associated with birthdays and Christmas by way of an icon. They were tied to specific dates only as a means of automating the archiving that I had been doing manually.

Intelligence layer

Using the magic of *AI*, I wanted to build something that could help guide users to become better list stewards and gift givers. Example ideas included:

• Nudge a group purchase on something nobody could afford alone
• Remember a tracking number
• Stash a gift receipt

Each one of those would require a fundamental schema change that no amount of additional duct tape and bubble gum could remedy.

The rewrite became the only honest answer.

HoffStuff was never built to share

The other thing the app couldn’t do was leave my family behind.

Once I saw my family using it, I knew I wanted to share the app with others, not as a service or a product, but as something other households could pick up and run for themselves, the same way mine had.

HoffStuff, naturally, had Hoffman-specific decisions hard-coded into it deeply enough that I couldn’t have handed it to anyone without notable changes first. A substantial (and embarrassing) cleanup pass on top of a frame that was already creaking didn’t sound fun.

In parallel, I’d been getting steadily deeper into self-hosting and finding a lot of joy in it. The home server running all the projects I’m hosting has gotten a little more elaborate every month for years. The end-to-end of running my own services on hardware I own has given me satisfaction in a way that paying somebody a monthly bill never has.

HoffStuff 2.0 could be a chance to do both at once:

1. Build the app properly
2. Build it so anyone can host their own copy

More on both of those coming soon…