"Wired Up, Not Wired In"

  • devops
  • ai
  • decision
  • product

A laptop died mid-week, which turned out to be a smaller problem than it should have been, and the fulfillment work quietly caught something I'd been missing about how close to launch I actually am.

Week of August 17, 2026

Progress

  • Continued designing laBoutique's side of order fulfillment and started implementation
  • Reviewed the most common and critical user paths for completeness — and realized fulfillment for store purchases hadn't been planned for at all
  • laBoutique's admin interface is up and running, along with the changes needed for fulfillment
  • Got the first successful call from laBoutique to srchParty's webhook — no logic behind it yet, just confirmed communication
  • Decided to move development off the Mac mini and onto a dedicated dev server

The Hard Part

The laptop dying could have been a bigger deal than it was. It ended up a non-event mostly because I've already been SSHing into a desktop machine for development — I just grabbed a backup laptop and kept going. That near-miss is what pushed the decision later in the week to actually build out a proper dev server: the mini failing would be far more disruptive than a laptop, since it's the machine everything currently routes through.

The more interesting problem was realizing, while reviewing the store's critical paths, that I'd never actually planned fulfillment. I thought I was closer to launch than I am, purely because "what happens after checkout" hadn't registered as its own piece of work — it wasn't real until I sat down and traced the path end to end.

Getting the webhook itself working was satisfying but modest — laBoutique can now successfully call srchParty, and that's it. The logic for what to actually do with that call is still unbuilt.

I also found myself arguing a but with Claude about some design/implementation decisions that it made early on about the integration layer in laBoutique (reminder: I've had Claude write 100% of that code), specifically what events are defined and as a result what event's the client (i.e. srchParty needs awareness of). The long and the short of it is that Claude decided to create events for both subscriptions and non-subscription fulfillment events.

My assertion is that the two need not be differentiated and it creates a certain kind of hard coding of product types in the event definition. Claude argues that subscriptions and products are fundamentally different and is actually following the stripe pattern. This still doesn't sit with me well so more noodling required.

Decision Made

Move primary development off the Mac mini onto a dedicated dev server. The laptop dying was a reminder that the mini is a single point of failure for everything — losing it would be far more disruptive than losing a laptop I've got backups for.

Had Claude build the webhook router, since it's pure routing logic. Along the way Claude also pulled the logging structure out into a shared function — the log message shape and the debug-check logic living in one place instead of duplicated at each call site. That's a pattern worth carrying into the broader logging revamp rather than something specific to this one router.

Next Week

Close out on the subscription vs product debate I'm having with Claude about the design of the event system.

Implement the srchParty side of the fulfillment integration — the actual logic behind the webhook call — and get the new dev server fully up and running.