A lowercase letter made our own database invisible to itself for a month

I've been building AtlasForgeX, a desktop tool that reads official company registers and surfaces companies with buying signals. One of the enrichment steps pulls financial data (revenue, growth) per company, and it's the most expensive step in the whole pipeline.

This week I found out we already had a server-side database with financials for over 50,000 companies, built from previous runs across all customers. The desktop client never checked it first. Every install went straight to the expensive lookup, every time, for the same companies other customers had already paid to fetch. Fixed it so the client asks the shared database before doing anything expensive, and contributes back what it finds.

While debugging that, I found a second, unrelated bug hiding in the same feature. One country's rows were written into the database with a lowercase two-letter code while every other country used uppercase. The query that reads that table filters on the uppercase version, so it silently skipped that entire country every single week. Nothing crashed. No error was logged. It just returned zero rows, and zero rows looks identical to "no data available yet." That's how it went unnoticed for weeks: about 18,000 companies from that one country never got a revenue estimate, and nothing in the logs pointed at why.

The lesson that stuck: a query that returns zero rows and a query that's silently filtering on the wrong value produce the exact same output. If a feature is supposed to cover multiple categories, verify each one actually shows up in the data with a real count, don't infer coverage from the absence of an error.