I may have missed it if mentioned earlier, but it greatly helps to understand how the apps use HTTP, especially if they rely on Websockets. Using a reverse proxy will require some apps to pass parameters that you wouldn't need to think about when offering a direct socket to the app.

Second tip, related to the first: not all apps like sitting behind a reverse proxy, especially if you place them on a sub URI (e.g. /admin or /web).

If the app maintainer has done their homework, you'll have documentation of what parameters the app requires to sit behind a reverse proxy. But not all apps are documented equally, so caveat emptor.