The front desk that never misses a call

The problem

Once payment precedes account creation, the checkout webhook is the only thing standing between a paying customer and no account at all. Stripe redelivers webhooks, fires its checkout and subscription events in an unpredictable order, and a buyer can close the browser the moment the card clears. Provisioning is not one write: it is an auth user, a profile, a clinic, a setup record, a subscription row and an outbound email, six side effects with no shared transaction.

What we did

Every checkout became a first-class object in its own table with a lifecycle, from pending through retrying to completed, failed or needs support review, keyed by a unique Stripe session id. Replays short-circuit on records already completed, the whole provisioning body is wrapped so any throw writes the failure and its message to the record before re-raising, and a buyer whose clinic already has a different active subscription is parked for review rather than silently double-provisioned.

The outcome

Every paid checkout is visible, diagnosable and recoverable from an internal console, with retry, resend and reopen. Retry re-fetches the live Stripe session rather than trusting stored state.

The problem

The purchase-first flow creates accounts for people who have never chosen a credential. The obvious shortcut is to generate a password and email it, which leaves a working credential sitting in an inbox forever. The design document rejected it explicitly as not worth the security and trust risk.

What we did

The account is created with a throwaway 32-byte random password that is never transmitted, and the buyer receives a one-time setup code instead. The same machinery serves verification, password reset and post-purchase setup: codes generated with a CSPRNG, stored only as HMAC digests, compared with a timing-safe equality check, expired after ten minutes, capped at five attempts and rate-limited to one resend every ninety seconds.

The outcome

No reusable secret ever leaves the system by email, and one code path covers three separate journeys.

The problem

The voice platform reports each call twice: one delivery carries the transcript and timing, a second carries sentiment, summary and the success verdict. They are separate deliveries and either can arrive first or be redelivered. A naive upsert lets a late first event overwrite an analysis that already landed, quietly wiping the successful-call verdict the dashboard counts.

What we did

The handler reads the existing row first and merges by event type, so analysis fields are written only by the analysis event and otherwise carried forward from what is already stored. The upsert is keyed on a unique call id so redelivery is a no-op, the payload signature is verified with a timing-safe HMAC inside a five-minute window, and calls whose metadata carries no clinic id are acknowledged and skipped.

The outcome

Call telemetry that is correct regardless of delivery order, and a public demo line that cannot pollute a clinic's numbers.

The problem

After-hours saves is the tile that proves the product's value, and it depends on knowing when a clinic is shut. Practices type their hours as prose into a textarea: Monday to Thursday 8:00 AM to 6:00 PM, Sat 9-1, Sunday closed. The answer has to be computed in the clinic's own timezone, not the server's, with windows that can cross midnight.

What we did

A parser expands weekday ranges with wraparound, reads times with or without minutes and meridiem, inherits a missing start meridiem from the end one, evaluates the call time in the clinic's timezone, and handles windows that span midnight. Where hours are blank or unparseable it returns nothing at all rather than a guess.

The outcome

A metric that is either right or absent, never fabricated, backed by a partial index so the count stays cheap as call volume grows.