Why publish this
Roadmaps say what is coming. They rarely say what is not, which means every unbuilt thing looks like a maybe.
These are decisions, not backlog. If one of them is what you need, you should know now rather than waiting for a version that will not arrive.
I will not hold your content hostage
The commercially sensible move is to make leaving expensive. Store things in formats only I read. Keep the important material somewhere you cannot easily extract it. Make the exit costly enough that people stay through dissatisfaction.
It works, and I am not doing it.
Your lyrics, plans, media and recordings live on your machine, in ordinary places, in ordinary formats. If you stop paying, you keep them. If you move to something else, you take them.
The reasoning: the people using this are volunteers running services and events. Making their exit expensive would mean holding their work against their judgement about whether this is still the right choice. If someone finds something better for their venue, they should be able to go... and I should find out why rather than being insulated from the answer by switching costs.
I will not put your content in my cloud by default
Recordings stay local. Media stays local. Plans stay local.
There is a cloud component and it holds what it needs to: your account, your plan status, device identifiers, and the address if you use one. Not your content.
I could offer cloud storage as a feature and some people would want it. What I will not do is make it the default, or the only path, because that changes the relationship. Content in someone else's storage is content you can lose access to... through a lapsed subscription, a company that fails, a policy change, or a dispute.
An event that happened once should not be one business decision away from being unavailable to the people it belongs to.
I will not build engagement features
No streaks. No notifications designed to pull people back. No metrics presented to make you feel behind.
The people using this are volunteers with limited time. Anything designed to increase their engagement with the software is competing with the actual reasons they are there. A volunteer should open this, do the job, and close it.
The measure of success is not time spent in the application. Ideally it is quite low.
I will not add features that need a specialist
Every capability has a version that is more powerful and one that is operable by someone with fifteen minutes. When those conflict, I take the second.
That means I will not build things requiring a trained operator... deep configuration surfaces, professional workflows with many stages, anything where the powerful version demands expertise the room does not have.
This costs me. Some of those features would be genuinely useful to teams that do have expertise, and those teams sometimes go elsewhere as a result. That is the trade: if I build for the expert, the volunteer is excluded, and the volunteer is who this is for.
I will not gate the preservation of events
Recording is on every tier including free, and it stays that way.
I charge for capability... more cameras, higher resolution, hardware encoding, crew tools. I will not charge for whether something that happened once is kept, because that decides on a venue's behalf which events are worth preserving, based on what they could afford that month.
I will not require an internet connection to run
A local event should not depend on someone else's infrastructure. If your connection drops, your service continues: the projector still works, the recording continues, the room is unaffected.
There are cloud features and they are additions. The core has to work in a building with no internet, because buildings with no internet exist and services happen in them anyway.
I will not claim reliability I have not earned
I will not describe something as field-proven that has not run in a real venue on a real day.
There is a strong pull the other way... building something, testing it thoroughly, and describing it as ready. I have learned repeatedly that thoroughly tested and field-proven are different, and the gap between them is where people's live days go wrong.
So the language stays careful. Built and tested means built and tested. Field-verified means it ran in a real venue. Those are different claims and I will keep them different, even when the careful version is less impressive.
What this list is for
Partly to be useful. If you need cloud storage as a first-class feature, or a deep professional configuration surface, this is the wrong tool and you should know that now.
Partly because writing down what you will not do is a commitment. A vague intention to be decent bends under pressure. A published list is harder to quietly abandon, and if I do abandon one of these, someone can point at this article and ask.
That is the point of publishing it. Not to claim virtue... to make it costly for me to change my mind without saying so.