A coach for the conversations, not the touches

The problem

A reply would stream beautifully into the chat, and then be gone when the player reopened the thread the next day. Nothing in the client was wrong, and the failure was invisible in development, where the process stays alive.

What we did

The route was sending its terminal done event and closing the stream before persisting the assistant message. On a serverless platform, closing the response is a signal the function may be reclaimed, so the write that followed sometimes never ran and left no error, because the process was already gone. We reordered the stream lifecycle so the database write completes first and the stream closes last, and added explicit error capture on both the primary write and the truncation-retry write, which had been failing silently.

The outcome

Conversation history became reliable, and the class of bug that produces no logs was removed rather than patched.

The problem

ProLine would give three excellent steps and cut off during the fourth. Raising the token ceiling alone is a cost decision, not a fix: a longer limit still truncates eventually, and the product had no way to even detect that it had happened.

What we did

We raised the output ceiling, turned on the provider's usage reporting so real token counts land in the database, and taught the route to read the finish reason. When it indicates a length cut-off, the route fires a second, short, non-streaming completion asking the model to finish concisely, merges the continuation, and records the truncation, the retry count and the continuation tokens on the message row. The system prompt was rewritten at the same time to require closure.

The outcome

Truncation stopped being a silent quality failure and became a measurable, self-healing event.

The problem

Real customers paid, the payment provider reported success, and their accounts stayed unsubscribed. Two faults compounded. A billing-mode change had moved the period end off the subscription root and onto the subscription item, so the webhook was writing an invalid date. Worse, the handler logged its failures and returned HTTP 200, which tells the provider the event was accepted, so it never retried. Every failure destroyed its own evidence and its own recovery path.

What we did

We read the period end from the root with a fallback to the first subscription item, and changed the handler to throw on missing metadata or a failed database write so the provider's retry machinery does its job. Founder-badge assignment moved into the subscription lifecycle handler so it survives a checkout event arriving out of order.

The outcome

Failed webhook deliveries became visible and self-retrying instead of silent. Both fixes shipped the same day the problem was reported on live payments.

The problem

The first cut of the message-insert policy checked only that the row's user id matched the signed-in user. It never checked that the thread belonged to them. The application never sends a mismatched thread id, so the hole was invisible from the UI and from any end-to-end test. It only exists at the database boundary, which is exactly where an authenticated attacker operates.

What we did

We wrote a dedicated security migration replacing the policy with one that also requires the target thread to be owned by the caller, added a unique index on the subscriptions table to kill the double-click checkout race, and added covering indexes for the admin and usage queries.

The outcome

Authorisation for the most sensitive table in the product is enforced by Postgres, not by the correctness of the client. In a product where players describe conflicts with their manager, that distinction is the whole trust proposition.

The problem

Early on, every message was answered in isolation. A player explained their situation, got good advice, asked a follow-up, and was answered as a stranger. Naively replaying an entire thread is both expensive and unbounded, and a football coach needs two different kinds of memory: what was said in this conversation, and what is permanently true about this player.

What we did

We separated them. The route loads the last twenty messages of the thread for conversational context, and a persistent player-memory document from the profile for identity, position, level, club, goals and weaknesses, injecting both into the system prompt on every request. Per-message input and output token counts are recorded so the cost of that context is measurable rather than assumed.

The outcome

Follow-up questions work the way a player expects, and the context window stays bounded and priced.