Building Screenlite. Part 4 – Slow development is intentional
The pace of development of Screenlite is slow, and that’s by design. At first glance, implementing features like authentication or screen management might seem straightforward. Technically, they are. But the slow progress has less to do with code complexity and more with understanding the landscape.
This industry has been around long enough that there is little value in pushing out yet another raw product. I’m not rushing to release something just to say it’s finished. Instead, I’m deliberately studying what has already been built and where other products have stumbled. There are a couple of open source signage projects, but there are also more than 500 closed-source products in the market. A quick look at public support forums, GitHub issues, and related subreddits shows a recurring pattern: almost every product goes through the same painful road of bugs, feature gaps, and awkward workarounds.
That pattern is instructive. The same issues come up across different systems. These are not just technical problems. They are product and UX problems. When I see a forum post where someone is confused about something, I don’t want to dismiss it as user error. I want to know why the system allowed confusion to happen in the first place.
So instead of developing what I think is right, I’m exploring what real users have already struggled with. That preparation phase takes time, but it pays off in implementation.
As part of this research, I’ve been actively following the r/digitalsignage subreddit. For the past three months, I’ve read almost every new post. I try to help when I can, or at least suggest possible solutions. Sometimes I just ask follow-up questions to better understand what users are trying to do. It’s one of the most direct ways to stay in touch with real-world use cases and frustrations. It’s also a reminder that even small features can have a big impact when done right.
This approach makes development feel slow, but it also makes it more thoughtful. I want this CMS to be clean, maintainable, and predictable. I want the most common actions to feel obvious. And I want developers to read the code and understand it without decoding layers of patchwork logic.
In open source, quality matters more than quantity. A smaller but solid feature set is better than a long list of half-working modules. The people who try open source tools tend to be technical and often contribute back. That means code quality, consistency, and developer experience are crucial. A rushed design will only result in more GitHub issues and more wasted time for everyone.
The digital signage industry doesn’t need another tool that checks boxes but ignores the details. It needs something that feels considered. My aim is not to build something big quickly, but to build something small that feels right.