Demos should be inclusive of all he work it takes to build a real, functioning piece of software. That should include the reliability work, the scaling, the testing, and the refactoring necessary to do real software engineering. And it should include APIs and containerization. So I guess I'm intending this as a fairly technical demo, but talked about from a customer and business perspective.
I personally think it's important for your stakeholders to understand the necessity of this work, and this gives the team the chance to talk about it.
Thanks for bringing up the failure mode of this -- I'll consider adding that to the blog post.
One thing to be careful of is that the demos are inclusive of all the work required to build functional software. Prepare the team to demo all the parts of their work: the APIs, the infrastructure, the reliability work, and the testing. If you're in an environment where there is less trust, or the leadership doesn't understand how software should be built, you may need to use the demos to educate and give context on the team's work. It's also important for you to cheerlead the work that isn't customer facing.
And added davidkunz to the Thank you section.
And any time spent on the non-visible portions of the project (at least 50% of the value) are seen as "waster" because there's nothing to demo.
Everyone else is thinking about getting new customers, and mostly with new features.
They only love to get into the details when product market fit is not working and they need to buy some time and get the investors off their back by justifying some large technical rewrite.
And it can fail when all you want to do is give a great demo. I've seen many showcases which couldn't be further away from real projects. Use cases are constructed which are taylored to your features, a little deviation and it won't work anymore.
But still, it's a good exercise to see your project a bit more in the eyes of your user.