Three Things Happen When You Submit Our Audit Form

When someone submits the Operations Engine audit form, the API route does three things before it responds: sends a confirmation email to the person who submitted, sends us a notification with their details, and creates a record in Airtable. Three I/O operations, one HTTP response.

The naive way to write this is three sequential awaits. Each call blocks the next. Total latency is the sum of all three. In a Vercel serverless function that has to respond before the client times out, sequential I/O is the wrong default.

Running Them in Parallel

All three operations are independent. The Resend call to the user doesn't depend on the Resend call to us. Neither depends on Airtable. So we start all three at the same time and wait for all three to settle:

const [userResult, notifyResult, leadResult] = await Promise.all([
  sendUser,
  sendNotify,
  recordLead,
]);

Total latency is now the slowest of the three, not the sum. In practice, Resend and Airtable both complete in 200-400ms. Sequential would be 600-1200ms. Parallel puts us at 400ms or less.

The await matters for a separate reason. Serverless functions on Vercel tear down as soon as the last line before return finishes. A fire-and-forget call, one you start without awaiting, gets killed mid-flight. We learned this the hard way earlier in the month when Airtable writes were silently dropping. Promise.all awaits everything, so the function stays alive long enough for all three writes to land.

Which Failures Are Acceptable

The more interesting design question is what to do when one of these writes fails.

The user confirmation email is fatal. If Resend fails to deliver it, we return a 502 and the form shows an error. The user sees the problem immediately and can retry. We also fire a PostHog exception event so we catch it in the dashboard if it starts happening repeatedly. The user experience depends on getting that email: it explains what happens next, sets expectations for the call, and states the audit price clearly. A silent failure here means a confused prospect who doesn't show up.

The internal notification email is non-fatal. If it fails, we log the error, keep going, and return 200. The user's experience is unaffected. We have the Airtable record and PostHog events to reconstruct the lead if needed. Losing one internal notification is annoying but not a broken pipeline.

The Airtable write is also non-fatal. Same reasoning: we log the failure, continue, and return 200. The user confirmation email already went out. PostHog has a server-side operations_engine_lead_processed event with the labeled service, timeline, and budget values. If the Airtable write fails, we can manually add the lead. Nothing is permanently lost.

if (userResult.error) {
  // fatal: return 502, user sees the error
  return NextResponse.json({ error: "Failed to send confirmation" }, { status: 502 });
}

if (notifyResult.error) {
  console.error("[operations-engine-lead] Notification email failed (non-fatal)");
  // fall through
}

if (!leadResult.ok) {
  console.error("[operations-engine-lead] Airtable capture failed:", leadResult.reason);
  // fall through
}

The Rule

Classify every write by who it affects. If it affects the user's experience of the form submission, it's fatal. If it only affects internal operations, it's non-fatal. Non-fatal failures get logged and skipped; they do not block the response.

This also defines the PostHog event placement. The operations_engine_lead_processed event fires after the fatal check passes. That means every time that event appears in PostHog, the user got their confirmation email. It is not a "form was submitted" event. It is a "form was fully processed from the user's perspective" event.

The distinction sounds subtle but it matters when you use that event to monitor pipeline health.