Six months into a dashboard build, someone asks a question that should be trivial: is this balance current?
And nobody can answer it.
Not because anything is broken. Because the balance card, the transaction list and the FX panel were built by three people at three different times, and each one arrived at its own private theory about how old data is allowed to be before it stops being useful. One refetches on focus. One polls every thirty seconds because that felt about right. One caches until you hard-refresh. Nobody wrote any of it down, so nobody can tell you which is correct — and now the question "is this number current" has three answers depending on where you look.
I've built frontends for banks — NatWest, US Bank, TIAA-Nuveen — and this is the failure I've watched happen most often. It isn't a coding failure. It's a sequencing failure: the team designed the component tree first and treated data freshness as an implementation detail to be settled per widget, per ticket, by whoever picked it up.
It's backwards. Freshness is a contract, and it belongs upstream of the architecture — because what you decide there determines your transport, your caching, your error states, and the shape of the boxes themselves.
