The edit that used to take the evening

The problem

An image model asked to improve a photo will happily reinterpret it. For a listing photo that is not an improvement, it is a misrepresentation: invented scenery behind a window, a redrawn house number, a straightened wall that was never straight. The constraint is not make it look good, it is change exactly these things and nothing else, across fourteen features that can be combined in any order on the same frame.

What we did

We rebuilt the prompt layer as one universal base with a single slot for active feature instructions, composed per render from individual feature modules. The base carries the hard rules: object integrity, text preserved character for character, geometry untouched unless perspective correction is active, mirrors explicitly not windows, and every feature scoped so that if its target is not visible it does nothing at all.

The outcome

Feature behaviour is defined in one file per feature instead of in variants of a monolithic prompt, so a rule fix applies to every combination at once. The refactor was cut against a tagged rollback point.

The problem

Stripe retries failed or timed-out webhook deliveries for up to three days, and can deliver the same event concurrently. Both cases can credit an account twice. The naive fix, a processed-events table, quietly creates a worse bug: if the handler commits the dedupe row and then fails partway through, Stripe never retries and the customer never receives what they paid for.

What we did

We used an insert-or-ignore into a webhook event ledger as both the dedupe key and a soft lock, so of two concurrent deliveries only one proceeds. On business-logic failure the claim row is deleted and the handler returns a 500, so the next retry can re-run cleanly. Each purchase type carries a second independent key as well, a unique Stripe session id on the purchase ledger.

The outcome

Every money-moving path is idempotent under both replay and concurrency, and a transient failure still ends in the customer being credited.

The problem

Usage checking is read-then-write. Two requests that read the same balance can both pass the check, and the app runs as more than one process against a single database file. An application-level lock does not help across processes, and an ordinary transaction only takes its write lock at the first write, which is after the read that made the decision.

What we did

Reservation runs inside a transaction that takes the write lock immediately, so a second process blocks rather than races. The deduction itself is a guarded update that only succeeds while the balance is sufficient, so an oversell is rejected by the database rather than merely made unlikely. The same guard covers the in-editor tool credits, and a failed render refunds what it reserved.

The outcome

Overspend is structurally impossible rather than improbable, and a failed render costs the customer nothing.

The problem

Object keys are structured by user and project id. Serving images by redirecting to the storage bucket's public URL made every customer's photography enumerable by anyone who could count. The obvious fix, streaming every image through the application, moves all image traffic onto the app and its egress, and the library loads dozens of thumbnails per page view.

What we did

We moved image delivery behind the session so every request is authorised against the owning project, then paid the bandwidth back with ETag and 304 handling, plus long-lived immutable caching for explicitly versioned URLs.

The outcome

Photos are private to their owner, and the library stopped re-downloading every thumbnail at full size on each refresh.

The problem

Batch renders continue in the background after the HTTP response returns. The host sends a termination signal with a short grace window before killing the container, and the persistent volume can mount after the process has already started. The work is not in a queue with an external broker; it lives in in-process promises, so nothing else knows it exists.

What we did

We tracked every in-flight batch promise in a set and drained it on shutdown, and made the container's start script poll for the data volume before booting the app.

The outcome

A deploy during an active batch finishes the batch instead of dropping it, and the app never starts against a filesystem that is not there yet.