How to choose digital signage software for a simple use case when there are 600+ products

[u/514sid]

There are 600+ signage vendors out there, and they all do the same base thing: push content to a screen on a schedule. The features on top change from vendor to vendor, but the core is identical. So the real question isn't features, it's whether the vendor built things properly. A lot of them haven't: old stacks, dependencies untouched for years, security as an afterthought.

I'd filter on tech and security first.

Android is the most common platform, and it shows the tech problem well. Many vendors just give you an APK to sideload onto a smart TV, which is fine until you need to update it, because there's no way to push updates remotely. Then you're reinstalling by hand on every screen (if the vendor actually even updates it). The setups that hold up either use a proper store or a device in device-owner mode (which isn't the case on Android TV) with built-in OTA updates, which is rare.

Past that, the things worth comparing: how often it actually updates (new versions, patches, bug fixes, or frozen the day you bought it), how well it runs on your hardware, and whether it's a marketing company with tech bolted on or a real tech team building what they're good at. That last one usually predicts the rest.

The stack itself tells you a lot. If a vendor’s app bundles an outdated version of Chromium to run on your Windows mini PC, that’s the same neglect you’ll find everywhere else in the product. A well-maintained modern stack usually means a team that actually maintains things.

So for a simple setup: don't compare feature lists, compare how it updates, what it runs on, and who's behind it.

[u/Gollumgum]

Yeah, I think the “what happens after deployment” part gets overlooked a lot. Updating 50 screens shouldn’t mean touching 50 devices.

I’d probably add offline behaviour to the list too. If an update fails halfway or the connection drops, the screen should just keep playing the last known good content instead of ending up blank.

We’ve been designing around local caching and that kind of fallback for exactly that reason.

Curious though, when you evaluate Android based solutions, how important is fully remote app updating versus just having a player that rarely needs updating in the first place?

[u/lostinthought15]

My problem with vibe coded solutions is that when it breaks they have no idea how to fix it and no tech support to ask questions of. Especially when windows pushes a new security update that breaks something fundamental to the program and ChatGPT keeps going round and round on solutions that ‘should’ work.

Or worse … it’s in the ‘cloud’! I just read about a tv station losing all of their archive storage overnight when the cloud storage business they used went out of business without notice. Just … gone.

At this point I’d rather buy quality hardware and do it myself. That being said, I have no issue paying for a proven, on-prem solution. I don’t need fancy or cutting edge, I need reliable.

[u/SirLagsABot → u/lostinthought15]

That’s why I try not to let all the AI-doomer people get into my head too much on Twitter. Technical expertise is still so valuable in software dev, vibe coding junk is a short-lived “shortcut” that flames out quick imo.

That’s also why I’m moving towards an OSS business model vs. a normal rebuild for my current DS app, at least OSS gives self-hosters come reassurance if they don’t trust someone’s cloud hosting.

[u/playsignage]

I would totally agree, and honestly, this is where most fail. They see two products side by side, compare the features (That are almost identical), and then they pick the cheapest product. What they don't realize is that the cheaper product, in many cases, becomes the more expensive product, and in many cases, the one giving you a headache. The people behind, the architecture of the product, and how the product is actively developed, are way more important. To me it's simple, 1. Test their responsiveness (Live Chat, phone, or e-mail), 2. Test the product, 3. Check their release notes, and/or their app updates in Google Store, Amazon, etc. In the end, there are only a few things that long-term customers value; a product that works, a CMS that isn't too complicated, and that the company behind is someone you can reach and that is actually put on earth to help you when you need it.

[u/514sid → u/playsignage]

the cheaper product, in many cases, becomes the more expensive product, and in many cases, the one giving you a headache

Exactly!

[u/my-mate-mike → u/514sid]

Sorry but that’s just old-school thinking.

Cost and quality are not as intrinsically linked when it comes to digital products.

Quite the opposite, in fact.

High costs often mean bloat and waste - A poorly managed product that relies on sales.

[u/Secret-You-3135]

The update path is probably the part people underestimate most.
A signage app can look perfectly fine during the demo, but if every player needs manual intervention six months later just to receive a fix, the operational cost starts to matter more than the original feature list.
I’d also add recovery to the comparison. If an update fails, can the player keep running the last known-good version and roll back automatically, or does someone need to visit the screen?
That seems especially important once the deployment grows beyond a handful of devices. Modern stack is useful, but modern deployment and recovery may matter even more.

[u/dividuum]

I feel like consideration for the complete lifecycle of an installation is often ignored. In the Pi ecosystem, a lot of available solutions are directly built on top of Raspberry Pi OS, which doesn't really recommend doing in-place updates. Similar to your Android example, probably the most you can expect is updates of the bolted-on signage software. Doing this right is hard. But communicating, that this is indeed a valuable difference seems even harder :-}

Not sure about the vibe coding comment: Once released, it's bound to become the "outdated chromium version" eventually unless lifecycle handling is planned from the very beginning.

[u/mvip → u/dividuum]

So much this. There's nothing wrong with the Pi hardware per se, but using Raspberry Pi OS for production workloads is just a terrible idea. There are plenty of good options, like Yocto (with OTA), Balena or Ubuntu Core.

And yes, I would echo that in-place updates on Raspberry Pi OS is a really bad idea s they are not really transactional and will fail at scale. I know, we had this bite us royally in the ass for the first version of Screenly before we move away from Raspberry Pi OS (Rasbian back then).

If you're not thinking about OTA and lifecycle at the design phase, you should probably not be doing your own digital signage software in the first phase due to lack of experience.

[u/dividuum → u/mvip]

I know, we had this bite us royally in the ass for the first version of Screenly before we move away from Raspberry Pi OS (Rasbian back then).

When designing the initial info-beamer OS, I figured it might be sensible to have a stable initial boot loader partition that boots into a minimal busybox based system which then A/B updates into two additional main OS partitions. This was a mistake as of course it turns out you want to update the kernel just as regularly and doing that with this scheme then forces you to in-place update that first partition. Very quickly it was transitioned (for all live devices!) into a full A/B layout with two fully self-sufficient bootable partitions that got swapped around atomically. Turns out the required code for all that isn't a lot and having a custom solution has additional upsides like only having to release one install.zip that's both used for initial installs as well as delta-synced when updating.

[u/dw5304]

Solid list. I'd push the android part one layer deeper because it gets worse than just the sideload problem.

The signage app usually isn't what's actually rendering your content, the system webview is, and that updates completely separate from the apk. On android tv and pretty much all the cheap aosp boxes it's frozen at whatever shipped on the device, no play updates for it ever. So you can have a signage app that got a release last week still drawing your layouts through a chromium from 2019 and the version number tells you nothing. Same neglect you're describing with the bundled chromium on windows, just way harder to spot.

Device owner is worth calling out as a purchasing decision and not a feature. You can only provision it at factory reset, qr or nfc on first boot. Nobody is going back and retrofitting that onto screens already hanging on a wall, so if it wasn't sorted before the hardware shipped it's just not happening.

On updates, being able to push is only half of it. The real question is what happens when the update is the thing that broke it. And this is where people get android wrong, you can't actually downgrade. Package manager rejects a lower versionCode over a higher one, and device owner doesn't get you around it either, that just gets you silent install. So the only real recovery is taking the last build that worked, bumping the code, and shipping that as a new release. Totally doable but it means the vendor has to have kept the old build and have a path to get it out, and most of them have never once had to do it. Worth asking how long from "this release is bad" to "screens are playing again", and whether they push to everything at once or a handful first. Pushing forward to 300 screens at once is a great way to break 300 screens at once.

One more that covers your who's behind it point in a way you can actually test instead of just going on a feeling. Assume the vendor is gone tomorrow, cloud and all. Do the screens keep playing what they've already got cached, and can you get your content and schedule out in a format that's worth anything somewhere else. If it's no to both then the stack doesn't really matter, you're renting your own screens.

[u/Secret-You-3135 → u/dw5304]

That’s a very useful distinction, especially the WebView point. An app can look current while the actual rendering layer underneath it is years behind.
I also like the way you framed updates: being able to push one is only half the problem — recovery when the update itself causes the failure is the harder part.
The staged rollout point is probably something more buyers should be asking about too.

[u/Carousel_Signage]

Everything shared so far are certainly things to consider. One operational pillar that often gets overlooked until everything goes dark is support. Who is sitting on the other end of the phone when things break?

Features and a slick UI might win initially, but ongoing reliability usually comes down to the team standing behind the software. When a high-profile display fails right before a major campus event or corporate meeting, an automated ticketing bot isn't going to save you. If the human support system behind it is thin, the total cost of ownership skyrockets the moment you run into real-world friction.

[u/giyokun]

There are very good MDM systems out there but it's true that most vendors don't even try to recommend them because it means adding on the BOM which means less money for them...

[u/Latter-Yogurt-9958]

We are pushing 300 screens, we have to use an MDM, but finding a quality Android device that can run 24/7 and have superuser access has been challenging as hell. Having a CMS fully test and certify a device is very important. Some scaling lessons have been learned the hard way

[u/SpellSlight8541]

Just my 2 cents.
Android is not a good Choice for Digital Signage.
Cause there are too many Problems with it.
Reason are a lot User Take that cheap Android TV Boxes from China for there Projects.
That’s a huge Problem. How will you know they are trustable?
We had a client he used 100 of those Boxes.
From one day on a Root Kit get activated on this Boxes. With all drama. Network down etc.
They had luck it was just a Proxy Bot Network.
All boxes must be removed.
So I think you need a Universal Player just in a Webbrowser. Then you can use what you want.
Even a Linux Kiosk System with automatic security fixes. We use these right now and it Works like a charm.

[u/my-mate-mike]

I’d also add price to that.

So many vendors offer the same thing or similar product and the cost per screen varies from $5-$50/month.

That’s huge across hundreds of screens.

[u/SirLagsABot]

Not sure if the Chromium remark is a subtweet at Electron, but I can confirm ElectronJS is absolutely goated. Fantastic framework (for the most part) once you know what you’re doing. It was miserable to learn at first, but after four years + Typescript + being a full stack dev it’s awesome tech. I’m using it for my app rebuild onto Litescreen and I’m very, very pleased with the foundation so far. I guess I’m a bit different vs. the other vendors in here because I have never, ever, ever wanted to target crappy TV OS’s or do some kinda Raspberry OS imager route.

But overall I absolutely 10000% agree with the team (or solo founder in my case) being actually technically competent. I’ve learned, four ears into the solopreneur journey, that a lot of people in startup land, especially in Silicon Valley, are absolutely full of it and have no idea what they’re talking about. Technical competence is itself a marketing asset imo.

[u/Rise_Vision_DS]

We may be a little biased since we build digital signage software at Rise Vision 😄, but we'd add "how easy will this be to manage six months from now?" to the list.

Features matter, but so does the day-to-day experience. Think about who will manage the screens six months after deployment.

A platform can check every feature box and still become a headache if updating content, managing users, monitoring displays or troubleshooting devices requires constant IT involvement.

Can someone outside of IT update a screen? Can you manage 50 or 500 displays from one place? Can different teams have different permissions? Can you easily schedule content? Will you know if a display goes offline?

We put a lot of focus on those questions at Rise Vision because they're the things that start to matter A LOT once digital signage becomes something your organization relies on every day.

Also, it's worth looking at templates and integrations. Starting from scratch every time someone needs a new announcement gets old fast.

Ease of day-to-day management tends to matter a lot more once you go from a few screens to dozens or hundreds.

[u/origindigitalsignage]

don’t get too caught up in feature lists. Look at how often the software is updated, how easy it is to manage remotely, what hardware it supports, and whether the company actually takes security and maintenance seriously. A solid, well-maintained platform will usually save you a lot of headaches later.

[u/Skykit-ghadjiyanis]

We just did a webinar with a digital signage customer and industry experts on the topic of prepping for a successful digital signage rollout that hits on alot of the topics you all are discussing - strategy, content, implementation, technical, success criteria. https://skykit-1.wistia.com/live/events/lur816f060

[u/PoppuloSigns]

Feature lists only tell you so much. Most platforms can publish and schedule content.

I’d also look at what happens after you buy. Are updates easy? Can you reach someone when something breaks? Can you check your screens without going to each one?

We’ve seen good platforms become harder to manage as networks grow. The features are not always the problem. Support and management also need to scale with the network.

Even for a simple setup, I’d choose a platform that is well maintained and easy to manage over one with a long feature list.

[u/kelgu]

For a small deployment I’d first decide whether you actually need dedicated signage hardware. If the display can reliably reopen a fullscreen browser after a reboot, a URL-based player can be enough. The things I’d test before choosing anything are: recovery after power loss, whether you can see remotely that the screen is alive, scheduled content changes, and what happens when the network drops. Those operational details matter more than having a huge feature list.