Shipping a SaaS feature end to end with Claude Code agents

The hardest part of being a one-person SaaS is not writing code. It is the context switching: you finish the feature at 6pm and now you owe the world a changelog entry, a customer email, two social posts and the energy to write them, which is exactly the energy you no longer have.

This is a walkthrough of how that whole chain runs as one Claude Code session with specialized subagents. The feature is real: usage-based billing for a Pro plan.

The command

> /ship-and-tell usage-based billing for the Pro plan

shipper: cutting scope. metering on API calls only, dashboard later.
billing-engineer: Stripe meter created. webhook verified. entitlements updated.
qa-engineer: 6 tests added on the billing path. all green.
changelog-writer: entry drafted.
email-marketer: customer announcement drafted, one CTA.
social-writer: two posts, different angles, your voice.

done. feature live, story told. 41 minutes.

Seven lines of output, but the interesting part is what happens inside each one.

Step 1: an agent whose only job is saying no

The first agent that runs is shipper, and it does not write code. It cuts scope. "Usage-based billing" could mean a metering pipeline, a live usage dashboard, budget alerts and proration. The shipper reads the request, reads CLAUDE.md, and decides what fits in one shippable slice: meter API calls, bill monthly, everything else later.

Every solo founder knows this discipline and almost none of us apply it at 11pm. Delegating the "no" to an agent sounds silly until you watch it save you a week.

Step 2: the specialist writes the dangerous part

Billing is where generic AI code hurts you. The billing-engineer agent carries its own rules: verify webhook signatures before touching the database, make handlers idempotent because Stripe retries, never trust amounts from the client, update entitlements in the same transaction. It reads the existing Stripe integration first, so the new meter code matches what is already there instead of introducing a second style.

Because it runs as a subagent with its own context window, it can read every billing file in the repo without polluting the main session.

Step 3: tests where the money lives

The qa-engineer agent is not asked to "add tests". Its prompt tells it to test the paths where money or data can be lost: the webhook with a bad signature, the retry that arrives twice, the user who downgrades mid-cycle. Six tests, all on the billing path, because a hundred tests on the happy path are worth less than one on the double-charge.

Steps 4 to 6: the story gets told while the diff is fresh

Here is the part that changed how we work. The marketing agents run in the same session, with the diff and the scope decision still in context:

• changelog-writer turns the diff into an entry that says what users can do now, not what the commit did.
• email-marketer drafts the announcement for affected customers, one CTA, in the voice defined in CLAUDE.md.
• social-writer drafts two posts with different angles, because the same news lands differently as a build-in-public note and as a feature announcement.

None of this is publishable blind, and that is fine. You review four short drafts instead of writing four things from zero. The marketing debt never accumulates, because the marketing happens at the moment the feature exists, and it works because every agent read the same CLAUDE.md before starting.

What you still do yourself

You decide the feature matters. You review the Stripe code before it ships, because it is your name on the invoice. You hit send on the email. The agents do not remove judgment; they remove the eleven context switches between your judgment calls.