Building internal tools to operate Plan Zinnia.

Repeated setup work was taking time from the product.

Expanding beyond venues to DJs, hair and makeup, or officiants required more than another marketplace listing.

Adding a category meant updating the database, creating forms, preparing admin approval records, tracking the work, and checking the result. The workflow took roughly half a day across engineering, design, and operations. Much of it repeated patterns we had already established.

I started with category setup: could one command prepare a consistent scaffold and the checks needed to review it? That became the Builder and QA workflow. Later, silent platform failures and the need to prepare vendor outreach led me to build Health and Upsell. Each addressed a specific operating task rather than trying to automate the whole business.

Choosing what to automate and where people act.

I used the same rule across the four tools: define a limited task, make its output inspectable, and be clear about what it can change. Builder prepares code and database artifacts; QA gathers findings; Health reports problems; Upsell drafts messages.

The model generates boilerplate from strong structural references: the enum name, design tokens, and the shape of an existing vendor experience. Git state, migrations, screenshots, and Notion logging sit around that generation step as deterministic operations.

These boundaries let me simplify category setup to one command while retaining the preview, logs, and findings needed for a review.

Apply the same boundaries to scheduled operations

Health and Upsell run on pg_cron schedules with service-role credentials. Their database reads use STABLE functions; their only persistent writes are their own history records. Reports and drafts go to people who can act on them.

The database restriction applies inside each read function. The surrounding workflow keeps operational actions with admins: Health surfaces problems, and Upsell prepares messages for a human to send.

Both agents also define what email silence means. Health sends recurring summaries and repeated failure reports. Upsell stays quiet when there are no drafts, but reports a failed snapshot.

Preparing a new category for review.

I built the Builder to reuse an existing vendor experience and the design system, then prepare the database and form changes for a new category.

The workflow can run unattended through generation, preview capture, and reporting. A person still inspects the scaffold and QA findings before approval. The model handles a constrained generation task; the surrounding steps use defined operations.

Attaching checks and evidence to the generated work.

The QA Agent runs automatically with --qa after a Builder run, or independently against any vendor route. Headless Puppeteer loads the integration URL and collects the signals a reviewer needs.

A thin Playwright layer in qa/tests/smoke.spec.ts runs scheduled checks against the public homepage. Builder-triggered audits and scheduled smoke tests write the same record format into a dedicated QA Notion database.

The Builder log and QA findings give ops and admin reviewers a visible trail from the scaffold to its audit results.

Finding failures in the running platform.

Several systems had quietly broken: Prerender had lapsed for three months, five edge functions had never been deployed to production, and new-message emails had stopped going out. The category-building workflow did not address this problem; we also needed a way to check what was already running.

Nothing was consistently checking the running platform. I built report-platform-health, a Supabase edge function that pg_cron runs daily, to email a structured report to admins and leadership.

The agent only persists its own history record. Database reads go through a Postgres function declared STABLE, which rejects writes within that function.

Preparing vendor outreach without automating the send.

The next operational task was deciding which vendors to nudge and what to say. I built draft-vendor-upsells to do that preparation every Monday.

The agent reads each Inquiry-plan vendor’s own data through upsell_draft_snapshot(): couples who reached out in the last 30 days, upgrade-intent signals, and time since the last nudge. This snapshot function is also declared STABLE.

A week with no drafts produces no email. A failed snapshot still sends an email, so a broken job cannot pass as a quiet week.

What changed in our operating workflow.

• New-vendor-category onboarding moved from roughly half a day of cross-functional work to a single command plus review.
• Every scaffold has visible QA findings before admin review. Builder-triggered audits and scheduled smoke tests use a shared QA record format.
• Deterministic templates provide a fallback when model credentials are missing or the generated response cannot be parsed.
• Platform checks became a scheduled daily report, with a full Monday summary and repeated notifications for unresolved failures.
• Weekly vendor outreach preparation became a Monday inbox item with usage-based drafts, cooldowns, and human control over sending.

The time comparison describes the onboarding workflow. It does not imply a measured end-to-end runtime or remove the need for review. Health and Upsell outcomes describe the operating workflow; no measured revenue uplift or reduction in incidents is claimed.