An expert practitioner beside every project

The problem

Some accounts had to be permanently free, the client's own and everyone on a partner domain, but free meant unmetered access to a paid model API. The obvious implementation, writing a plan and a large credit balance onto the account, was the wrong one: the Stripe webhook, the team-sync trigger and the nightly trial-expiry job all write to those same columns, and any of them could silently revoke the exemption.

What we did

We made comp status derived, never stored. It is resolved at read time from the verified session email against an exemptions table, and nothing in the feature ever writes to the plan or credit columns, so no existing write path can undo it. Domain matching is exact equality rather than a suffix test, because a suffix check would have matched an attacker-registered lookalike domain and handed it unlimited model spend. The lookup fails closed: any database error grants nothing.

The outcome

A nineteen-commit feature ending with the matcher covered by sixteen unit tests, including the revoked-row path. It also surfaced a live billing trap, where a comped user who also held a real subscription lost their cancel button and could be charged with no way to stop it, fixed in the same series.

The problem

The AI gateway needed a per-user ceiling. The normal approach, an in-memory counter, is useless on a serverless platform where each function instance has its own memory and a burst of requests lands across several of them, so the limit resets under exactly the load it exists to control.

What we did

We counted the limit from the usage table instead, ten successful calls per rolling sixty seconds, measured with a query against shared state rather than process memory. Credits are checked before the upstream call so a user can be refused without spending anything, and debited after success through an atomic Postgres function that decrements under a sufficient-balance guard and raises an error when the guarded update matches no row.

The outcome

A spend ceiling that binds across every instance, and a credit ledger that cannot be driven negative by two concurrent requests. The rare lost race is handled explicitly rather than ignored: the model call already happened, so the user still gets their text and the usage is still logged.

The problem

Recent Stripe API versions removed the top-level subscription field from the invoice object and moved it deeper into the payload. The invoice-paid handler read the old location, found nothing and returned early, so renewals were never provisioned and the receipt and welcome emails never went out. Nothing errored. Paying customers just quietly stopped being upgraded.

What we did

We wrote a version-tolerant resolver that reads the subscription id from either location and returns nothing only for genuinely non-subscription invoices such as one-off credit top-ups.

The outcome

Renewals provision again, and the webhook is now resilient to that class of API drift rather than to one specific payload shape.

The problem

The billing emails had two faults that both damage trust: a payment-failed notice that fired when nothing had failed, and a triple-send where one event produced three identical messages.

What we did

We fixed both, added a database-level guard against duplicate welcome sends, and expanded the set to ten transactional emails covering the trial lifecycle, billing events and credit exhaustion. Language is resolved from the locale stored on the user's profile rather than from request context, so an email fired by a webhook hours after the user left still arrives in their language. Credit warnings fire only on the downward crossing of the threshold, so a user near the limit is not emailed on every subsequent call.

The outcome

Ten bilingual templates that degrade gracefully to a no-op when the mail provider is unconfigured, so a missing key in a preview environment cannot crash a checkout.

The problem

The client arrived with a finished single-file prototype that worked and that they liked. The risk in any rewrite is that behaviour quietly changes and the client's confidence goes with it.

What we did

We ported it into 104 TypeScript modules while keeping the original stylesheet as global CSS rather than re-implementing the design in a utility framework, so the visual result is the same by construction. Every ported statistical function carries a line reference back to the prototype it came from, and the file forbids improving the formulas. Behavioural bugs found during the port were fixed and annotated at the call site rather than silently changed.

The outcome

Roughly 25,900 lines across 104 files, with the design preserved and the maths verifiable against the original line by line.

The problem

Projects, comments, actions, versions and assignments all had to be visible to a whole workspace but invisible across tenants. The natural way to express that in Postgres row-level security is a policy that queries the membership table, which is itself protected by a policy, which recurses.

What we did

We put the membership check in a security-definer function so the policy can call it without re-entering row-level security, then applied one predicate consistently across every application table: you may see a row if you own it, or if it belongs to a team you are an active member of. The events table the payment webhook writes to has no policy at all, so only the service role can touch it.

The outcome

Thirteen tables with row-level security enabled on every one, across fifteen migrations, sharing a single auditable visibility rule.