We get asked for things. Some we build quickly, some we decline, and the reasoning is consistent enough to be worth writing down.
The Question We Ask First
Not "would this be useful". Nearly everything is useful to somebody. The question is whether we can still be running it properly in five years.
A feature is not a one-off cost. It is documentation, support tickets, a security surface, and something that has to keep working through every future change. A small team can maintain a small number of things well, or a large number badly.
What We Decline
Things that duplicate something better. We are not going to build a worse analytics package than the ones that exist.
Things one customer wants shaped exactly one way. Usually better solved by giving that customer access to do it themselves.
Things that sound impressive and change nothing. An AI assistant in the control panel would demo well. It would not make anyone's site faster or their mail more reliable.
Things that add a failure mode to a working system without a proportionate benefit. Complexity that only pays off when everything is fine is a bad trade.
What Gets Built
Things that remove a support ticket. If several people ask how to do something, the answer is usually to make it visible in the panel rather than to write a better reply.
Things that let you check us rather than trust us. Usage figures, uptime, incident history, your own backups.
Things that reduce the number of steps in something you do often.
Why We Say So Publicly
Because "we do not do that" is a legitimate answer and it is more useful than a roadmap promise that never arrives. If a feature you need is genuinely central to your business, better that you find out now than after moving in.
Occasionally we get this wrong and reverse it. That is fine. It is a cheaper mistake than shipping everything and maintaining none of it.
