A product audit is not a deliverable. It is a process. The difference matters because most of what goes wrong in service businesses happens in the gap between payment and delivery, and that gap is usually invisible to the buyer.

The Prompt-Led Product audit pipeline is built to close that gap with a structured status lifecycle, automated buyer communication, and a feedback loop that fires whether or not the buyer remembers to respond.

Here is how the whole thing works.

The Moment Payment Clears

When a buyer completes checkout for a Flash Audit or Deep Dive, a Paddle webhook fires and writes one row to the audit_purchases table. The row captures the buyer’s email, the audit type, the Paddle transaction ID, and a status of confirmed.

Simultaneously, an audit-receipt email is enqueued. The receipt directs the buyer to their account dashboard, where the intake form is waiting.

Nothing about the audit work has started yet. The purchase is confirmed. The buyer has their receipt. The next step is entirely in their hands: filling out the intake form.

The Intake Form

The intake form lives in the account dashboard at /account. It collects three things:

• ✅ A description of the product and the specific problem they want audited

• ✅ An optional product URL

• ✅ Up to 3 supporting images (screenshots, onboarding flows, error states), each up to 10MB

Images are uploaded directly to a private Supabase Storage bucket called audit-submissions. Signed URLs are used for any admin access to those files. Nothing in the audit materials is publicly accessible.

When the form is submitted, an audit_submissions row is created and two emails fire: one to the buyer confirming the intake was received, and one to me (hello@elenacalvillo.com) notifying me that a new audit is ready to start.

The intake email to the buyer does a specific job. It sets expectations: what I will look at, how long the process takes, and what the deliverable will contain. That email exists because the most common source of service anxiety is not knowing what is happening after you pay. The receipt email confirms the transaction. The intake confirmation email confirms the work is starting.

The Status Lifecycle

Every audit moves through four status values:

confirmed → the purchase cleared, intake form not yet submitted in_progress → intake received, audit work started delivered → deliverable link attached, buyer notified closed → feedback received or 14-day grace period elapsed

I manage transitions through the /admin/audits dashboard. When I move an audit to in_progress, I can optionally trigger a notification to the buyer. When I mark it delivered and attach the deliverable link, the audit-status-notifier edge function fires the audit-complete email automatically.

The status field is the source of truth for everything downstream. The buyer’s account page shows their current audit status. The feedback nudge cron checks this field. The admin dashboard filters and sorts by this field. Nothing about the audit state lives anywhere except this one column.

The Deliverable

What I actually deliver depends on the tier.

A Flash Audit at $950 produces a friction log, a 10-minute Loom walkthrough, and a prioritized fix list. Delivered within 3 business days of intake submission. The Loom is the most important component because it captures the exact moment-by-moment experience of a first-time user in a way that a written list cannot.

A Deep Dive at $1,900 includes everything in the Flash Audit plus a full prompt logic review, a Bot Voice Check on any AI interactions in the product, a 3-step fix roadmap, and a 30-minute live Q&A. Delivered within 5 business days.

The Monthly Partner at $3,700/month is a subscription. One Deep Dive per month, weekly async check-ins, launch reviews, and 24-hour email access. It also grants full Vault access for the life of the subscription.

The pricing reflects what I actually build to produce the output, not a multiplier on an hourly rate I invented. The Flash Audit takes less time than the Deep Dive. The Deep Dive has a live Q&A that the Flash does not. The structure is honest about what you are paying for at each tier.

The Feedback Nudge

Five to seven days after an audit is marked delivered, a cron job called audit-nudge-dispatcher checks the audit_purchases table for rows where status = 'delivered' and feedback_received_at is null.

For every eligible audit, it enqueues an audit-feedback-nudge email to the buyer. The email is short: did the fixes land, what was most useful, anything that missed the mark.

This nudge fires once. If the buyer responds and I record their feedback, the feedback_received_at timestamp is set and the nudge does not fire again. If they do not respond, the status transitions to closed after a 14-day grace period.

I built the nudge because feedback is the most useful thing a service business gets, and most buyers do not remember to give it unprompted. The nudge does not feel pushy because it arrives at the right time: after the buyer has had a few days to implement something and see whether it worked.

What a Real Audit Finds

Two examples from actual audits, included here because they illustrate the specific type of failure the pipeline is designed to surface.

For Skyp.ai, the friction point was a missing CTA preview. The product had a full CTA builder that worked correctly. Users could construct their CTA and add it to an email campaign. But there was no way to see what the CTA would actually look like inside the email before sending it.

The final step in the creation flow asked users to trust output they could not verify. That friction was causing abandonment at the moment the user was closest to completing their goal. The fix is now part of every Skyp.ai demo.

For Rezonant, the friction point was a team invite flow that required Gmail domain matching. From an engineering standpoint, it was a reasonable security measure.

From a user standpoint, every solo PM who tried to invite a collaborator with a different email domain received a failed invite with no explanation of why.

The entire solo PM segment was functionally blocked from the collaboration feature. I flagged this before launch. It was fixed before a single real user hit it.

Both of these failures were invisible from inside the product team. The onboarding looked correct. The success states fired. The database had data. The failure only became visible when someone who builds the same type of product walked through the actual flow with fresh eyes.

Book an Audit

If you have a product where the onboarding looks fine from the inside but you suspect something is breaking in ways your team cannot see, that is exactly the scenario this pipeline exists for.

Book at promptledproduct.com/audits

Flash Audit delivered in 3 business days. Deep Dive in 5. Monthly Partner slots are limited.