"Week 081 — Coins, Stars, and the Store"

The Found Page bug graveyard got one more occupant Monday, and then I spent the rest of the week on a feature I hadn't planned to write yet.

Week of June 8, 2026

Progress

Monday started with the phone validation bug that had been sitting unresolved at the end of last week. The fix turned out to be embarrassingly simple once I actually looked at it: leftover code from when I was validating field formats manually. When I switched to letting the input mask handle format enforcement, I only removed the format checks themselves — not the surrounding logic that was short-circuiting the required-field check. Once I stripped that out, required fields started failing correctly when empty. I felt dumb about it for about thirty seconds, then moved on.

With the Found Page in better shape, I pivoted to the storefront. I'd decided last week that I was going to build it rather than buy or rent. Monday I started sketching out the design with Claude Code — high-level stuff, mostly structure. The question that surfaced almost immediately: what exactly do Coins do?

Wednesday was schema work. I made solid progress on the structure and had a useful back-and-forth session with Claude on the design, but the Coin question kept getting in the way. The more I tried to nail down what Coins could do, the more uncomfortable I got. Coins as an in-app currency — something users accumulate, spend, potentially transfer — starts to look like virtual currency, which is a regulatory category I have absolutely no interest in accidentally entering. Walked back from that direction.

Thursday I landed on a stable design. Coins stay. Stars stay. But they're distinct now:

  • Coins — earned through the product (not purchasable directly), with a balance that can go up and down. Earned credits, not currency.
  • Stars — cumulative and permanent. A community reputation measure. You earn them, they don't go down.
Both sit on top of a shared schema between the catalog and the storefront. The user sees two different surfaces, but the underlying infrastructure is the same.

Thursday also produced some UI cleanup. I pulled the cloud out of the logo, converted the header to a fixed size to minimize how much vertical space it consumes, reduced the desktop max width to 768px, and added some padding to make the layout feel less sparse.

The Hard Part

The storefront design was harder than expected — not because of implementation, but because of what it forced me to think through. Once I started mapping out what Coins could actually do, I was one step away from something that looks like a virtual currency product. The line between "earned credits" and "virtual currency" matters from a regulatory standpoint, and crossing it without noticing would have been a genuinely bad surprise.

Pulling back meant redefining what Coins are. They still belong in the system — they give the reward engine something to distribute that isn't real money — but their scope is narrower now: earned, not purchased.

The AI pairing on the storefront design was useful here. Claude helped me work through the schema options quickly, but the legal concern came from my own discomfort as I was typing the requirements out. Sometimes articulating a design is what surfaces the problem with it.

Decision Made

Shared schema between catalog and store. Different user-facing surfaces, same underlying structure. Keeps the data model simple and avoids having two representations of the same things that need to stay in sync.

Coins are earned, not purchased. Stars are cumulative. Neither is transferable. This felt obvious in hindsight but took most of the week to arrive at — mostly because I had to figure out what I wasn't willing to build before I could define what I was.

Next Week

Take the storefront from schema and design into actual implementation.