Week 082 — The Full Vibe

There's a version of this week's post where I just talk about what got built. I'm going to try to write the more honest one.

Week of June 15, 2026

Progress

Monday started with something I'd been meaning to capture properly: why I decided to build the storefront instead of buying or renting one. The short version is that off-the-shelf solutions are built for general use cases, and the catalog/store combination I need isn't a general use case. There's also the recurring cost argument, and the fact that I've been thinking more and more about software in a pre-commercialization sense — write it to solve your problem, not to be a product. With AI tooling lowering the floor on what one person can build, that's actually a viable posture again.

Tuesday I started the experiment. I'd already planned to use Claude Code more heavily on the storefront build, but Monday's reflection pushed me to go further: I'd go full vibe. No reading code, no spot-checking output. Prompt, review plan, accept, observe.

I started in plan mode in Claude Code, but when I asked to review the plan more carefully, it offered me something called ultraplan — a tool I'd never seen before. I went with it. It built everything in the cloud and needed GitHub access to push to my repo. First time I've used GitHub for srchParty; I've been on a self-hosted setup until now. Not a dealbreaker, just unexpected.

Getting it running was more physical comedy than technical heroism. Docker Compose stalled on a bad image version. Then failed on missing environment variables because the .env file wasn't mounted. Then failed because I hadn't run composer install in the container. Then had no data because I hadn't run the DB migrations. Each step: Claude pointed out my failure cheerfully, I fixed it, we moved on.

Once it was actually running, I was honestly impressed with how much was there. The catalog and cart areas were functional — add items, avoid duplicates, update quantities, upgrade and downgrade subscriptions. Claude made some opinionated calls I didn't specify, but none of them were wrong. Bugs existed, but most of them traced back to missing requirements rather than broken implementation.

Wednesday was cleanup and consolidation. I addressed the minor issues with the cart and Stripe integration, then made a call on Stripe's role going forward: only subscriptions require Stripe products. One-time purchases and coin redemptions don't. Documented how the admin interface should work — LaBoutique is the source of truth, and it interfaces with Stripe to create whatever it needs on that side. Ran DB migrations, stripped the remaining Stripe code out of srchParty, and finally removed api-item.php, which had been sitting deprecated since the item page refactor. All of this was productive in the measurable sense.

The Hard Part

Wednesday was productive. Wednesday was also the first day in this project where I didn't look at any of the code I was responsible for.

That sounds like a small thing. It didn't feel like one.

When I've used Claude Code before, the pattern has been: I write code, CC reviews it. Or I describe a problem, CC writes a snippet, I read and integrate it. There's been collaboration, but I've always been at least a spectator of the output. This week I was something else — closer to a manager than a developer. I reviewed architecture and design, approved plans, observed behavior in the running product. But the code itself was alien to me.

The output was real. The progress was real. I could not have moved that fast without it, and I'm aware of the pressure I've put on myself to ship. That pressure doesn't make it easy to justify slowing down.

But there's something disquieting about owning code I've never read. Not a moral discomfort — more like the feeling you get when you rely on a tool you don't understand. If it breaks in the right way, I won't know where to look.

The other thing that came up Tuesday was context and memory across AI sessions. The way I've come to think about it: every new Claude Code session is like a new developer joining the team. They're smart, they'll read the relevant code, and they'll get up to speed on the immediate task. But they don't carry the full context of why things are the way they are. That's usually fine early on. As the system gets more complex, it probably isn't.

I know there are tools for managing session memory. I don't yet have a clear picture of how much of that needs to be manually maintained versus what gets picked up automatically. That's a real gap.

Decision Made

LaBoutique is the payment layer; srchParty gets a webhook receiver. Stripe code is now fully out of srchParty. LaBoutique owns the Stripe integration and fires signed events back. This simplifies the payment story significantly and draws a clear boundary between the two systems.

Only subscriptions require Stripe products. One-time purchases and anything involving coins live entirely inside LaBoutique's own catalog. No need to maintain parity in Stripe for every item in the store.

Admin interface is the source of truth for the store. LaBoutique manages the catalog; it creates and syncs whatever it needs in Stripe. I don't maintain two copies.

The Question That Appeared

What is the right amount of Claude Code? Not as an abstract principle, but specifically for me, on this project, right now. The answer isn't "use it for everything" — this week demonstrated that clearly enough. But the answer also isn't "keep it at arm's length," because the productivity delta is real and the shipping pressure, despite self-imposed, is real.

I think there's a version of this that I'd actually feel good about, but I haven't found it yet.

Next Week

Get the integration between srchParty and LaBoutique working — specifically the checkout lifecycle and whatever needs to happen on the srchParty side to hand off to the store cleanly.