I try to get the program being able to be useful informative, easy for data entry, etc. After that - if I get the time - I can go onto enhancing other features like the style sheet (now that you got a good idea of what styles it utilizes its much easier to optimise the CSS to make it skin-able.)
Integrations and import/export is a pretty nebulous thing, and if you are interacting with some proprietary system you are always needing to maintain the export/import code to stay compatible (not that easy). Depending on the format you may run into licensing issues to get interoperability, in others some of the local dev or external use tech might not be mature enough to implement well or correctly.
"Just put an undo on it." "Detailed and up to date guides in text with screenshots at each step and highlights"
Yeah. sigh If the development and team is mature these things will eventually happen. But then comanies fall back when they are riding high on just maintenance and loose the experienced members; then new devs that come in are so overwhelmed on the legacy codebase they just re-write from scratch, picking some bits to reimplement, and loosing a lot of others.
Then again,
you put a knowledgeable developer in to the planning process and they would surprise you "We could reorder this entry process here and cut more than half the time on data entry", "That report on the old system is redundant, here's why" and "have you ever thought of doing this cool feature? Because that would be so easy implement..."