The tables nobody opened

I built the feature I was proudest of, watched a real business use it for two weeks, and deleted the whole thing. Not because it was broken. Because deleting it made the product more correct.

What it was

Every email that arrived got read and filed into four tables: the people she deals with, money in, money out, things in transit. Bookkeeping as a byproduct of mail arriving. You don't enter anything, you don't forward anything, you don't tag anything — you just get email, like you already do, and the books fill in behind you.

I loved it. It's the most impressive-sounding thing I've built. Every email cost three or four extra round-trips to the model to keep those tables fed, and I considered that money well spent.

The tell

She never opened the page.

Not once, in two weeks. And when she asked Dustav a question about money — what did I spend at the printer, did this customer pay — Dustav didn't read the tables either. It went and searched her Gmail.

Its own author didn't trust them. That's the moment the feature was over, I just hadn't said it out loud yet.

Dominated on both axes

When I finally sat down and asked what question the tables were the best way to answer, there wasn't one.

For a specific lookup — one receipt, one customer, one order number — searching the actual mail wins outright. The mail is authoritative, it's complete, and it's already indexed by a company with rather more search engineers than I have. My table is a lossy scrape of it, assembled by a language model, two months deep.

For a total — what did I make this quarter — the real books win outright. Her payment processor reconciles. Her accountant reconciles. A best-effort digest of whatever happened to land in her inbox is a report, and nobody wants a second, worse set of books sitting next to their real ones, disagreeing.

Specific: lose. Aggregate: lose. I'd built a cache nobody read, and paid for it on every single email.

Why deleting it made it more correct

This is the part I didn't see coming, and it's why this isn't a cost-cutting story.

I expected the pitch to be "slightly worse, considerably cheaper." It wasn't. The version without the tables is better at answering questions, because it answers from the source instead of from a lossy copy of the source. Every wrong number the old version could produce came from the copy having drifted, or the scrape having misread, or the row having been merged with a different row that looked similar. All of those failure modes went away with the tables.

The cheaper part was real too — three or four model round-trips per email collapsed to about one, and the cost per email fell from around twenty cents to eight. But I want to be precise about the order of the argument, because I keep seeing people get it backwards: I didn't remove a good feature to save money. I removed a feature that was making the product worse, and the savings were a side effect.

The worse problem underneath

The tables were also a guess about what kind of business you run, and I'd charged everyone for the guess.

Four tables — customers, income, expenses, shipments — describe a shop that sells physical goods. That's the business I was watching, so that's the business I encoded. Point the same product at a realtor and she pays, on every email that arrives, for a shipments table that will never hold a single row, and an income table shaped like retail orders when her income is commissions. Point it at a fitness instructor and it's worse.

I'd hardcoded one vertical as universal and billed everyone for the parts that didn't apply to them.

What's left, now that the tables are gone, is the set of things that are true of every operator I've talked to: mail arrives, someone is owed a reply, there are dates in it, there's work owed, and there are people you deal with. Nothing in the reader assumes what the business sells anymore. That's not a smaller product. That's the first version of it that could be handed to a stranger.

The one that survived, and the one I got wrong

One table lived. Contacts — the people she deals with — because of a genuinely different reason: when you start typing a name into the To field, the suggestion has to appear on the keystroke, and you cannot run a mail search per keystroke. That's the test, and it's the only test I now apply:

Keep a copy only where querying the source live cannot serve the use case.

Contacts passes. Money doesn't. And here's the honest correction, because I got one row wrong: shipments should have survived too, and it failed for a bad reason. A tracking number is a stronger key than an email address — the carrier issues it, it's globally unique, and it appears verbatim in every message about that shipment. And "what's in flight, what's late" isn't a search at all; it's a diff between ship notices and delivery confirmations. That's real state with a lifecycle. It passes the test. It died anyway, because it rode the same lossy machinery I'd built for the money tables, and I tore out the machinery with everything on it.

I got the rule right and applied it wrong on one row. Worth saying out loud, because "delete the whole subsystem" is a satisfying move and satisfying moves are exactly when you stop checking each case.

The inversion

The good news is the new shape makes that mistake cheap to fix, and this is the structural payoff I want to leave you with.

In the old design, adding a vertical feature meant adding a table that every business had to maintain. Shipments were mandatory for the realtor. In the new one, the reader produces a single structured answer per email, and a vertical feature is one more field on that answer plus a branch that files it. Only for businesses that ship. Additive, not mandatory.

The old architecture made specialization expensive for everyone. The new one makes it free for the people who don't need it — which is the only way a small product gets to serve five different trades without becoming five products.

The one-sentence version

I spent three model round-trips per email maintaining a copy of data the agent could already read, for a business shape half my users don't have — and the day I deleted it, the product got cheaper, simpler, and more likely to be right.