Disposable Shiny Apps (James Wade, Dow) | posit::conf(2025)
Disposable Shiny Apps Speaker(s): James Wade Abstract: Many data scientists find themselves building Shiny apps for one-off presentations, client meetings, or teaching demonstrations. These "disposable" apps can suffer from overengineering, leading to unnecessary development time and complexity. Or, the apps never get built because the development hill is too high to climb. This talk covers disposable Shiny apps - intentionally minimal applications designed for specific, short-term needs. We'll explore strategies for rapid development, including reusable templates, coding assistants, efficient styling, and design principles that prioritize speed and clarity. This talk will show how this approach can transform a typical week-long development process into a few hours while maintaining polish. Materials - https://github.com/JamesHWade/posit-conf-2025 posit::conf(2025) Subscribe to posit::conf updates: https://posit.co/about/subscription-management/
image: thumbnail.jpg
Transcript#
This transcript was generated automatically and may contain errors.
Good morning, everybody. I am really excited to be here today to talk to you about disposable shiny apps. I want to start with my goal for today's talk, and that's to convince you that you should build more shiny apps and then throw them away.
So my name is James Wade. I'm a chemist and data scientist that works in a research and development environment, and I build shiny apps, a lot of them. I have lived the production side of shiny apps. In fact, I got to skip out on an app release 30 minutes ago, attending the keynote instead. And I also have been maintaining this two-year-old shiny app that has more than 100 users. It has tests, CICD pipelines, a backlog that I feel guilty about not getting to, and I really have learned both the power but also the pain that these long-living apps can yield. I've also increasingly come to appreciate the disposable side. I build apps for a single meeting, they live for an hour and die gracefully, or more likely just live on Posit Connect for nobody to pay attention to them, and I've really come to appreciate the power of immediacy.
Something else about me is I have a common frustration giving presentations that I imagine many of you have come across as well. Let's say you've been asked to give an important update to some high-level stakeholders, you've crafted your narrative, you've spent time to polish your slides, make them beautiful, you're telling your story, and thankfully the stakeholders there are paying attention. Maybe one of them unmutes, asks you on a data slide, hmm, that's really interesting, but what if we looked at the data this way? Your answer, if you haven't thought of that, is I'll have to get back to you. The conversation stops, the momentum is lost.
What you're often building, what I am often building in my presentations is something like a painting that might live in an art gallery. I'm not an artist, but please bear with me for the analogy here. The intention is for the audience to listen, to hear a message, and maybe take an action from that, but it's very passive in nature. Something else about me is I have young kids, so I end up spending a lot of time in children's museums, and if you've never been to these or if it's been a while, these are glorified playgrounds, but what I love about them is they have exhibits that invite the children and sometimes parents to interact, play, sometimes even break the exhibits that are inside of them. Hopefully you get the analogy here.
I want you to answer for yourself what the goal of your given presentation might be. Do you want that active engagement? Now, maybe you're thinking this would be great. I'd love to have time to go build some of these more apps, and you might be falling into one of two traps. The first is the don't build it trap. It's too much effort just for one meeting for you to go and build this out. We default going back to slides because the development hill feels just a bit too steep. Maybe you go on the other side. Maybe you know yourself well enough that if you start building an app, you're not going to stop. Maybe you think it has to be production grade. Maybe you're going to overengineer a complex solution for really what should be a simple app. The result of both of these is death by PowerPoint.
The result of both of these is death by PowerPoint.
The disposable app mindset
I want to challenge you to think with a new mindset, this disposable app. What if building an app for a single meeting was just as easy as making a slide deck? The value of this application is for its immediate impact, not for its longevity. It's a communication artifact, a communication tool, not a production system. Again, it's designed to be thrown away.
So how do we go about building one of these? I'll do this through an example. I'll walk through a critical tool at least in my life, which is the twin potty trading command center.
One thing to consider for these applications is that it's becoming much easier to build them because of a paradigm shift that all of you are familiar with. This development hill isn't as steep as it used to be, largely because of vibe coding. And what I mean this more broadly of the coding AI assistance that can dramatically accelerate the time it takes to get to a working application. We can translate our prompts directly into functional Shiny code.
When we're doing this, critically for a disposable app, what you're going to want to do is start with one question, one intent. A disposable app should do one thing and probably only one thing well. So going back to the potty training command center, my house has twin toddlers in it that are currently going through potty training. I have a four-year-old, I have four cats and a lot of chaos. My house is never quiet. And one of the questions we had was how do we know if we're making progress with our potty training? So the important stakeholders here are myself and my wife. We're wanting realtime insights and encouragement to think that we're headed in the right direction with this.
So here is the app itself. It has the ability to track how each of the twins are doing. It has a parental sanity meter as part of it. You can interact with this. Most importantly is the chat bot that gives us that encouragement. In case you have kids that are potty training age, we're using oh, crap potty training. I don't know if it's any good because I don't know if we're going to succeed at this. But one of the things it did say was don't tell anybody when you're going to potty train your kids. So I guess I made a bit of a mistake there.
Building with AI assistance
If I were giving this talk two years ago, what I would have done, say, the old way of making this, I would have started by defining the question, the same step you already saw. I would have encouraged you to go get a template, maybe sketch out a UI, start building the UI itself, maybe writing some server logic and then going through a couple of iterations of styling and polishing. It's not drastically long that would have taken me. I've built a lot of these and I could probably build something reasonable in a couple of hours. But the new way of doing this, we can change this workflow. We're going to define the question, but we can go and start writing a prompt that we can use with one of these coding assistants. I'll go through the other steps in a moment, but I time boxed myself in the app that you saw to 15 minutes. It took 12 minutes in total to get to the application that you saw. That is not something to look at me and be like, wow, he's good at that. It's a testament to the capabilities that are now possible.
More on that in a moment. So let's talk about this. What does a clear prompt mean? This is not a talk on prompt engineering. I'm not the expert on that. But I can give you some tips and tricks that I have found for this. Really what you're wanting to do is explain to a colleague the application that you would want. The clearer you are about that, thinking of things such as a clear objective, tracking the twin potty training progress. Maybe some features, a success rate, predictions, the components that you already saw. Specifically calling out tools that you want to use. Asking for BSlib. I wanted a sidebar layout. And having enough context that the application is actually going to be recognizable. So I let it know that my twins' names are Henry and Penelope. The better the prompt, the more time you're going to be saving yourself later on.
Now, just to show you this, this is what the prompt actually looks like. I'm not going to read all the way through this. That's not really the point here. I want you to get a sense of how much information is required to get something useful out of this. So, again, this took about 12 minutes for me to go and make the app that you saw. And let's think of why that actually worked well. I'm not some mystical 10X engineer, if any of you were at the keynote a few moments ago. What I'm using is a lot of other infrastructure and tools around me. I opened up Positron. I'm using Positron Assistant. I loaded in the Shiny extension. I'm using a frontier model, in this case, Claude Sonic 4. I'm styling it with brand.yaml, which you'll hear about later in this session. And I'm deploying it to Posit Connect. I'm not even mentioning all the different packages that I'm also, the open source packages that I'm using that's helping accelerate this even further. So, it's not really magic, despite what I have on the slide here that we're talking about.
But you can take this short paragraph or so, and if you're feeling particularly lazy like I am at times, you can just talk and have it transcribe what you're having to say. But, again, including those details that are going to increase the likelihood of a success on the first couple of iterations of an app. You really do need to watch this happening. Most of the vibe coding, so to speak, that I've been doing has been with Claude Code. And I find it particularly helpful to read exactly what it's telling me back it's going through. I can see it going down weird avenues, and I can stop it going through that.
What you can see using these capabilities is you already saw the UI components. You see a UI structure using Shiny and BSlib. It did a realistic data simulation. It had interactive visuals. I didn't ask for interactive visuals, but it gave me those. It uses Elmer in Shiny chat as part of this. Now, I should mention that it didn't actually work the first time it came out. There was an error. But all I did was copy that error, paste it in, and a couple of iterations, I think it actually took three, I had something that was workable for me. And now that I know about the fix slash command, it would have been even faster for me to go through that.
So, pretty often you're going to be finding yourself having to fix some of these broken pieces that come along the way. Maybe you see a style or layout that you don't particularly like. Maybe you need to add in some of your own data. But sometimes I actually see the app comes up and it isn't answering the question that I started off with. Maybe it was poorly posed or isn't actually going to be useful for the audience that I want to consume this information. And in that case, maybe I'll start again or maybe I'll just throw it away. Again, I've invested only 15 minutes. I spent a lot more time on that adjusting figure layouts in my presentations.
Another important key to success here is having a push button deployment environment. The barrier to getting somebody your tool that you've created, if you want it to be disposable, needs to be just as easy as that initial app creation process that you went through. For me, it's Posit Connect. I really appreciate the ability to just push the magic button and all of a sudden I now have an app that others can interact with.
Addressing objections
Okay. So you've heard this so far, but maybe you're thinking that this isn't exactly something that's going to be for you. I want to take a couple of moments to talk through some of the possible objections that you might have in your head as part of this.
The first of which is who's going to support this? In my role, I'm often asked about things like life cycle management, support structures. Maybe the IT department is going to call me up and ask, what's the maintenance plan for this app? Very simple. Nobody is going to support this. That's the entire point of it. You don't need a maintenance crew for a whiteboard drawing. You just erase it. We don't have support structures for our PowerPoint slides. If it only took 15 minutes to build and we need it again, we can just go and rebuild it.
The second objection, isn't this in danger of just creating a bunch of app sprawl? If any of you have a push button deployment environment like I've described, it's probably a mess. I actually think that's a sign of success. It means people are using it and taking advantage of it. So, yes, I do think that you're going to be in danger of app sprawl. And to be honest, I'm not the right person to ask about this because I've been accused of being an app hoarder myself. I think the value there is rather than worry about having the making sure that only apps that should live the test of time will make it to this deployment environment is to rather focus on curation. And most likely you're not even going to be focused on surfacing something that you could end up throwing away. The key distinction here is the role that this disposable app is going to play. These are communication artifacts, not an underlying production system. You must be committed to if you're going to create this, if you're going to acknowledge that it can die, you have to be willing to let it do so.
Third objection, this sounds like more work. Is it really faster than making slides? Let's think about what I did for this presentation. I realized early in some of the speaker coaching sessions that I was definitely obligated to build an app if I'm talking about how easy it is to go and build these. And so what I had to do is I had to create these slides and I created an app. Have I now just created something that's going to be more work for all of you? Maybe. But I would argue that the impact to effort ratio that you have here is much higher. If that app happens to land, that's going to have a much more profound impact on your audience than if you simply had spent that time making the slides instead. I've noticed that PowerPoint for me can be an infinite time paradox where I just will spend way too much time tweaking where all the layouts happen to go. Actually, that's when this presentation was built in Quarto, which actually prevents me from being able to do that since it's all specified in code. The other thing to acknowledge is it's way more fun to build a shiny app than it is to put a presentation together. I imagine that many of you are going to agree with that as well.
The other thing to acknowledge is it's way more fun to build a shiny app than it is to put a presentation together.
So I want to go back to really what I was talking about at the beginning here of my challenge to all of you of wanting to build more shiny apps. This is going to require a mindset shift. The barriers to creating these apps are gone. We have more of these tools. The challenge that we have is to rethink how we can use these applications in a disposable manner. So my challenge to all of you is the next time that you have a presentation, I'm going to challenge you to open up RStudio or Positron before you open PowerPoint and to go and build something that's disposable. Thank you.
Q&A
Thank you, James. We have time for a few questions here. First, how do you handle user input? For example, if you have a dashboard and the value is wrong but the user wants to edit to fix the data somehow?
That's a great question. I think in that case, this is a danger zone for some of these disposable apps of where you're wanting to take user feedback and refine it. I think the challenge that I would have there is see if the point of the app is not to hand somebody a tool. Again, it's to hand somebody that communication piece. And so a couple of back and forths I think are fine. But I actually would resist the urge to go and do interface refinement unless you have achieved likely the outcome of the meeting and now they're inspired to have something long term. So you might end up creating more work for yourself in the long run by having these. But that just means more shiny apps for the world.
For shiny apps used in meetings, what do you do to prevent in-meeting crashes that can halt momentum?
If anybody knows how to make the live demos go well, I would love the advice on that. For the most part, what I had here, that was just a recorded animation of the app in action. That's one way that you could accomplish something like this. But if the app is crashing on you repeatedly, most likely you've tried to create something that's too complex. That's the benefit of actually having that deployment environment. It's rare if I have a simple app that it will end up crashing because I'm not going to build out external data connections or other dependencies that can have the bugaboos that will face true production deployments.
How did you prepare your organization for this going from PowerPoint slides to the shiny? Do you see meetings running more successfully now?
I would say that I have not spread this message adequately well in my own company. But people like looking at something other than PowerPoint. I imagine many of you like looking at something other than slides. And so having that interactivity can be something that's really pleasant. One of the signs of success I would have, I would say for this, is if you are sending out an app and you're getting questions of people using that, potentially even instead of listening to your talk. Sometimes that actually is the end goal of I want somebody to just start using something. It's similar in my mind to how when I'm talking to somebody about whether they should use AI-based coding assistance, nothing that I say is usually going to convince them to go do it. They just need to experience that sort of wow factor on their own. So same thing with the power of interactivity.
Sure. How do you think about sharing disposable apps in your org? For example, you mentioned Posit Connect. If someone doesn't have an account but they may need to view an app one time just quickly, how do you handle that situation?
Have lots of licenses. In practice, I think that most disposable shiny apps, this one would not be a great example because it has a chat bot. But that likely would be a great example for Shiny Live, where you could have it so that you could just send it to somebody. If anybody here works for Microsoft, I do have a complaint that you can't paste a Shiny Live app into a Teams because the link is too long. So if anybody wants to fix that, I'd be really happy about it.
So for presentations, you can save a PDF copy, but if you delete a shiny app, then no one else can access it. Is it worth it to have that workflow knowing that you can't save and share in that same way?
Yeah. Good question. I mean, I think you could save some of the artifacts. You don't literally have to delete it, although I did. I didn't go to the final animation. I should have deleted this application in style. But I think in those cases, you are looking for more inspiration or action as the intent of that communication artifact. But that is a good point. That certainly is a downside. My museum analogy that I spoke about before, by the way, I think that I don't want to say that you only should be focused on building the children's museum equivalent. There are cases where you just want the audience to absorb it and listen. And similarly with these disposable apps, I think that's a good fit for where if they get the message, they no longer need the app, hopefully.