Consider optimizing the images on your landing page -- 6.87s and almost 20mb transferred to load a couple images.

Will this menu be printed as well?

If so, then have you considered using LaTeX? I would code the menu in LaTeX, then use the PDF to print and display online. Reduces the amount of places you need to manage changes.

http://tex.stackexchange.com/questions/38091/document-class-for-a-restaurant-menu

As a supporter of Overcast I'm not happy.

The most annoying thing is the move to a two-step method for playback (which Marco rightly recognizes is a controversial change).

From a UX perspective it's an infuriating change -- it now takes 100% more time to perform the same primary functionality (playing an episode), tap episode to reveal tray menu, tap play button vs. just tap the episode.

In addition to adding the additional step, by moving the Play button to the tray menu he's weighted it the exact same as ancillary tasks like Add to Playlist or Share. I use the app because it is literally a podcast PLAYER, not a podcast sharer or podcast add-to-playlister.

Given the size of the tray menu, it is now much harder to tap Play when "on-the-go" because it's so small (by my napkin math estimation, the new play button tap area is 1/10th the size of old "just tap the episode" method.

Pretty amateur UX mistakes.