One idea, solved twice: software that lives inside the tools staff already use — so there's no new system to adopt, and no retraining to survive.
Two teams, two unrelated systems, the same failure: the software asked people to leave the tool they knew and work somewhere new.
One team processed applications inside a legacy student system; another verified case data across Salesforce and the state's TWC TEAMS portal. In both, the "solution" on the table was a separate app — one more login, one more thing to learn, one more place for work to fall through. Adoption dies there. The complexity had to move to the software, not the staff.
Both became a browser extension: a thin layer that appears inside the page staff were already on, reads the context, and does the hard part in place. No migration, no training day — the tool shows up exactly where the work already happens.
Guides teams through application processing with a step engine, warnings, and stage advancement — layered onto the existing student system.
Authenticates to Salesforce, then autofills and cross-checks TWC TEAMS — catching CASAS and profile discrepancies before submission.
Meeting staff inside a live system means reading data constantly. Done naively, that's a database read on every render — and a bill to match.
A fresh read on every interaction. Costs and latency climb with every active user.
One live listener per document, a local cache with a 5-minute TTL, denormalized fields, and batched writes.
The same pattern worked twice, for two teams that never met — because it never asked either of them to change how they work.
That's the transferable part. Not the code, not the framework — the decision to put the software where the people already are. It's why staff adopted it without a rollout, and why the approach outlives any one system it was built on.