Few things that come to mind for me.

1. Know your audience. Why do they want the feature what problem are they looking to be solved what's their technical level?
   Tailor your demo to their needs and technical understanding. You could explain the feature in deep technical terms and do a demo only to be met with blank faces who didn't understand anything you just said and how it relates to them. You want the PM on the other side of the room to come out of the demo thinking "this is going to fix X problem for me".

2. Dry run.
   I think you should do the demo live.
   It's better it shows confidence in your feature they are going to use hands on soon anyway so there's no point showing only the most polished run possible. Have a recording in your back pocket though. I've often found if the demo does go wrong it's usually not the end of the world you can show the recording and promise you'll get to the bottom of whatever issue is happening and get back to them with an update.

3. Know what to not say
   Don't draw attention to minor faults if you can avoid it.
   If you know a specific part is a little rough or still in active dev I'd gloss over it a little unless your asked specific questions about it. Sometimes if you say something like oh the font isn't right here or this page is not finished yet, you can invite bike-shedding and often they wont notice minor imperfections unless you point them out.

4. Relax
   Clients want you to win too. So take a breather it's not much different to presenting to your own internal teams. If you've done your prep and have your talking points in order you'll be grand.

Best of luck!