Why 'invisible' is the best word a client can use to describe your work

A few years ago I inherited a problem with a hard deadline attached to it: a teller-facing application depended on an Adobe Flash component to display a webcam feed, and Flash was being sunset industry-wide. The component had to go. The deadline wasn't negotiable.

The obvious move — the one a lot of vendors would have pitched — was a redesign. New interface, modern video component, maybe a training session for staff while we were at it. I didn't do that, and I think not doing it was the right call.

Clients fear disruption more than they fear cost

Tellers had a workflow. It worked. The webcam feed was one small part of a screen they used dozens of times a day, and every one of those uses was already muscle memory. Swapping in a "better" component would have meant retraining, support tickets, and a week of tellers hunting for a button that used to be somewhere else.

So instead I built a lightweight local HTTP server that served the webcam feed in a format the existing interface could consume without modification. From the teller's chair, nothing changed. The Flash dependency was gone before its end-of-life date, and as far as I know, not one person who used that screen every day ever noticed the migration happened.

Invisible is a feature, not a compromise

It's tempting to read "no visible change" as "we didn't do very much." The opposite is true — matching an existing interface's exact behavior from a completely different underlying implementation is usually harder than building something new from scratch. There's no blank canvas to hide behind; every edge case in the old behavior has to be accounted for, because someone downstream is relying on it without knowing they're relying on it.

If you're evaluating an integration project and the person quoting you can't explain what won't change, that's worth a second question.