Zero Bugs

Tell someone you run a zero-bug policy and you'll usually get a raised eyebrow. Zero? Every bug? Always? It sounds like a slogan a founder puts on a careers page and quietly ignores by the second sprint. We're adopting it anyway, because for the kind of software we build, no other number makes sense.

The idea isn't ours. Linear has run a zero-bug policy for years, and they make the most important point up front: fixing a bug costs the same whether you do it today or in eighteen months. The work doesn't shrink by waiting. All that waiting buys you is a longer stretch of users hitting the same broken thing, and a backlog that everyone privately knows is a graveyard. Most "we'll get to it" bugs are really "we'll never get to it" bugs wearing a nicer label.

What changes for us is the stakes. Linear is where you plan your work. Expensicat is where your money lives.

A bug in a finance tool is never cosmetic

When a project tracker miscounts something, you lose a little trust and a little time. When a tool that handles your invoices, your VAT, your bank reconciliation, and your tax prep gets something wrong, the blast radius is different. A misread total. A category that quietly drops a transaction out of a report. A reminder that fires on a paid invoice, or worse, doesn't fire on an unpaid one. None of those are cosmetic. They show up in what you charge a client, what you owe a tax office, and what you believe is sitting in your account.

Our users are freelancers, solo founders, and small teams. They don't have a finance department to catch a discrepancy, and they don't have a procurement process that assumes the software is occasionally wrong. They have a quarterly deadline and a trust that the number on the screen is the real number. A backlog of "minor" bugs in that context isn't minor. It's a slow tax on the one thing the product is supposed to protect: confidence in your own books.

So the question we ask isn't "is this bug worth fixing?" It's "would I be comfortable telling a user we knew about this and left it in?" The honest answer to that, almost always, is no.

It's the foundation the AI sits on

We build around a simple division of labor: the AI handles the routine, humans handle the exceptions. Cat categorizes transactions, matches receipts to expenses, drafts invoices, and flags the things that look off — and every one of those decisions is reviewable and correctable. That bargain only works if the ground underneath it is solid.

An assistant that confidently acts on top of a buggy foundation doesn't save you time, it multiplies the error. If the data layer occasionally drops a transaction, Cat will reconcile around a number that was never right, and do it faster than you can catch. Automation makes correct systems more useful and broken systems more dangerous. Zero bugs is the price of admission for letting software touch your money on your behalf.

How we actually run it

A policy without mechanics is a wish. Here's how this one works.

Every bug that comes in gets triaged, and triage has exactly two outcomes: we fix it, or we explicitly decide not to and say why. There's no third door marked "backlog" where things go to be forgotten. The deadlines are blunt — high-priority bugs within 48 hours, everything else within a week — but the deadlines matter less than the ritual they create: bugs get handled first, before feature work, while they're still cheap and still in context. Fixing a bug the morning it lands is a few focused hours. Fixing it six months later means re-learning code you've forgotten, in a system that's moved on without you. We'd rather pay the small bill now than the compounding one later.

There's a quieter effect, too. When a team knows it will have to fix every bug it ships, it gets noticeably more careful about shipping them. A zero-bug policy doesn't just clean up after mistakes — over time, it prevents them. That's not a metric we can put in a changelog, but it's the part that compounds the most.

Zero is the only honest target

We could pick a softer number. "We fix the important ones." "We keep the bug count reasonable." Every team that says that is quietly deciding which of your broken experiences are acceptable, and hoping you're not the one living in the 1%.

When it's your money, that framing falls apart. We'd rather be right 100% of the time with your help than wrong 1% of the time without it — and a tolerated backlog is just a slower way of being wrong. So the target is zero. Not because we'll always hit it on the first try, but because it's the only number we're willing to defend to the person whose books are on the line.

It's the same instinct as the hero at the top of this page: the bugs keep coming, and you keep clearing them, all the way down to zero. Then you do it again tomorrow.