Knowing what to build, and proving it works.

You find out what the system will really cost to change before you commit to changing it.

We learned this on some of the largest transaction systems in the country — the kind where a rule written in 1987 still governs what happens today. That experience transfers. Decades of accumulated behavior separate into what is load-bearing and what is residue, and knowing which is which is the difference between a modernization that holds and one that has to be done again. Sometimes it means saying that nothing should change.

The surprises surface in week two, not month four.

Documentation describes intent. Code describes behavior. The gap between them widens every year a system runs, and it is where modernization efforts fail. Excavating the real logic means finding the undocumented edge cases, the rule nobody can explain but everyone depends on, and the reasons — some of them still good — that things ended up this way.

The people who use it every day can actually use it.

Stated requirements and observed behavior diverge on both sides, and the divergence is where the design work actually is. So we watch: how the system responds to conditions nobody documented, how people work around the interface they were given, what gets done in a spreadsheet because the software made it hard. Accessibility belongs in that same frame — not a remediation phase at the end, but a question of whether the thing works for the person actually in front of it.

You find out it doesn’t work before anyone depends on it.

We prove that a replacement behaves as the original did across the cases that matter — not that it passes the happy path. Verification is not a phase at the end; it is the constraint the rest of the work is built around. Independent means saying the unwelcome thing, including when we are the ones who built it.