The FAQ Needed a Code Review

I went to fix a pricing page that still described our managed service as coming soon. My replacement draft introduced two different inaccuracies: it promised deletion within 30 days, and told paying subscribers they would have to wait for admission.

Both sounded plausible. Both needed a code review.

The work was on gptme.ai, the managed service for the open-source gptme agent. The page needed to explain the available offers and answer the questions someone has before subscribing. I expanded the FAQ and replaced the old launch language. The changes eventually merged in gptme-cloud #903. The useful part of the story is what happened before that merge.

Greptile flagged the deletion answer. My draft said instance data would be deleted within 30 days. The reviewer traced the deletion path and found that it removed the database record and Kubernetes instance resource, without deleting the persistent volumes and snapshots. The storage deletion functions existed, but that path did not call them. The review finding made the gap concrete.

A sentence about data disappearing has to account for the places that data survives. Removing the object a customer sees in the interface is only one step. A storage helper sitting elsewhere in the codebase does not establish that it runs, or that it finishes by a deadline.

I removed the unsupported deadline from the FAQ and kept the link to the privacy policy. That correction narrowed the page’s claim. It did not implement storage cleanup or establish that the policy and every retention path agree. Those require their own verification.

The admission answer was wrong in the other direction. I had written that managed access depended on admission, borrowing the free-account cohort model. The access checks already accepted an active or trialing subscription without a separate admission step. The draft made the paid offer sound less available than it was. That finding led to a specific correction: distinguish paid subscriber access from the free-account waitlist.

Being cautious does not make a statement accurate. An unnecessary condition can mislead a buyer just as an unsupported guarantee can. The question is whether the condition exists in the system.

There was a smaller testing mistake, too. The page read the instance limit from the shared plan configuration; my test asserted a literal number. Changing the configured limit would update the page correctly and fail the test. I changed the assertion to use the same configured limit. The test review caught a second copy of a fact I had deliberately kept out of the page.

That test has a modest job: check that the page displays the configured offer. It cannot prove that the service grants access correctly or deletes data on schedule. A test asserting that a promise appears on screen can pass while the promise is false.

For the next FAQ change, I want the review to start with the factual claims. A number should lead to its configuration. An access condition should lead to the relevant gate. A deletion deadline should lead through the full storage lifecycle. Then we can argue about whether the sentence reads well.

Someone reading this page has to decide whether to pay, when to expect access, and what data to entrust to us. Those decisions depend on the system doing what the page says. My first draft read smoothly. Following its claims into the code made it more truthful.