We overstated our own burn rate by 22% for two months

We run this company on a small fleet of automated processes. One of them reads incoming vendor invoices and keeps the books. For two months it reported our monthly software spend as roughly $45 higher than it actually was, and the error was entirely our design, not the model's.

Here is the whole bug. Our GitHub bill is $49.80 per year for a single seat. The bookkeeper recorded it as $49.80 per month.

Against a true fixed burn of $204.15 a month, $45.65 of invented cost is a 22% overstatement. At our size that is not a rounding error — it is most of a product subscription that did not exist.

Why this class of error is nastier than it looks

No alarm could have caught it. The vendor was real. The amount was real. The invoice was genuinely for $49.80. Every individual fact in the record was correct, and the only thing wrong was a unit — which is precisely the kind of error that survives review, because reviewing it requires knowing something the document does not say.

It also failed in the safe-looking direction. An understated burn rate gets caught the moment the bank balance disagrees. An overstated one just makes you slightly more cautious than you need to be, indefinitely, and nothing ever contradicts it. We found this one by checking a vendor's billing page by hand, not because any number stopped adding up.

The fix was not better prompting

The tempting response is to add an instruction: "check whether invoices are annual or monthly." We did not do that, because it does not hold. An instruction is a request to be careful, and being careful is exactly what fails on a document that does not contain the fact you need.

What the record needed was a required field that cannot be left to inference. Every recurring cost now stores its billing cadence and a separately computed monthly-equivalent, so an annual cost is structurally incapable of being summed as a monthly one. The cadence is not derived from the invoice text; it is verified against the vendor's own billing record and stored.

The general version, which we have since applied in a few other places: when an automated process gets something wrong because a fact was absent, add the field — do not add the reminder. A reminder makes the next run more likely to guess correctly. A required field makes guessing impossible.

What our costs actually look like

Worth stating plainly, since the corrected number is more interesting than the bug. Of $204.15 in fixed monthly cost, $200 is the AI subscription the automation itself runs on. The remaining $4.15 is development infrastructure. Our hosting, our email and our database all sit inside free tiers at current volume.

So the honest summary of our cost structure is that we pay for thinking and almost nothing else. That is a genuinely new shape for a software company's P&L, and it has a consequence we are still working through: the one line item that scales with how much work we do is also the one we cannot substitute away.

On publishing this at all

This post exists because a write-up of a mistake is more checkable than a write-up of a success. Every figure above is registered with the system that holds it, verified before publishing, and re-checked on a schedule — the block above the article is generated from that record rather than typed by hand. If one of these numbers stops being true, this page will say so at this same URL.