Wild HQ makes things it wants to exist, then offers them to other people without trying to own those people.
This page is the compact between the instincts and daily product behaviour. Product-specific documentation may add detail. It may not quietly lower these expectations.
Public works in public
Public pages should have meaningful URLs, work without an unnecessary account, preserve browser navigation, and remain linkable. Public serial content gets RSS and JSON Feed when practical.
Private material stays private because a person chose it to be. “Public by design” is a capability, not permission to expose someone by surprise.
We collect less
Wild HQ collects and keeps only the information a current feature needs. It does not buy missing personal information elsewhere, build speculative profiles, or sell people, behaviour, or history.
When a feature needs new data, its documentation should make the purpose and retention understandable. A useful feature that can work without identifying someone should work without identifying them.
Do not send passwords, tokens, private customer information, or unnecessary personal data when asking for help.
You keep control
Recommendations, rankings, and automated choices must be understandable, adjustable, or disableable. There should always be a direct path controlled by the person using the product.
Notifications must justify the interruption. Marketing does not become urgent because a system can send it.
Custom pages remain the person’s pages where the product promises that freedom. Wild HQ may constrain code or content for concrete security, safety, abuse, or reliability reasons—not to protect people from harmless taste.
Leaving should work
Useful exports, documented formats, and migration paths matter. A published API should be usable without case-by-case permission, within clear and reasonable limits.
Old URLs, builds, documentation, changelogs, and decisions stay available where practical. Ending support does not require erasing the record.
If Wild HQ cannot keep a product alive, it should leave the people using it with the most practical path available: exports, migration tools, documentation, a self-hostable release, or another durable option. The exact path depends on what can be delivered safely, but lock-in is not the fallback plan.
Unfinished and unsupported are honest states
Wild HQ may release something before it is complete when real use will teach more than private guessing. The unfinished parts should be named. “Early” is not an excuse for rotten foundations, unsafe data handling, or pretending a missing capability already works.
Support and service operation are provided by volunteers on a best-effort basis. There is no implied response-time or uptime promise. Known limitations, outages, maintenance, and endings should be communicated plainly rather than hidden behind cheerful status copy.
Products should remain humane
Success is not measured by addiction, time spent, notification opens, or how hard leaving becomes. Accessibility, understandable behaviour, privacy, portability, and the time a product gives back to people are product qualities, not optional polish.
When a Wild HQ product falls short of this compact, report the concrete mismatch. An instinct is useful only when it can correct what Wild HQ actually does.