We read every feature request. We don’t ship every feature request. The difference between “we’ll do this Friday” and “thanks, we’ll consider it” is almost always how the request was written.
What makes one ship fast
A specific job
“When I’m reading the report, I can’t tell which findings are above and below the NFR threshold without scrolling back to the dashboard.”
This describes the moment the user hit friction, the task they were trying to finish, and what would unblock it. We can build to that.
A user, not a persona
“I’m an agency owner, I run Site Check on every client site before handover” — one real person, one real workflow. We can ask follow-up questions. We can prioritise based on whether ten users would benefit or one.
One thing
A request for a single change always beats a request for five things. “Add a download-as-PDF button to the cert page” ships in a sprint. “Redo the cert UI to be more modern with PDF/CSV/JSON export and a dark mode and a different colour palette” doesn’t.
A “no” you’ve already considered
“I don’t need full PDF customisation — just the existing layout exported. If you only have time for the simple version, that’s still useful.”
Tells us where the floor is. Even a 10% version of your idea is shippable.
What slows requests down
- “It would be nice if Site Check did more / was better / had more features” — too abstract
- “Why doesn’t Site Check just be like X?” — comparison without context, no actionable change
- “Build me a dashboard that shows everything about my site” — scope is everything, ship nothing
- Five things in one request — we can’t prioritise pieces against each other
Where to file
- Most things: the Feature ideas Community board — public, peer-visible, others can +1 or comment with their version of the same need
- Bugs you found: /feedback/bug-report — separate flow, more structured
- Customer-specific requests: email [email protected] — we triage faster when there’s revenue impact
What happens after you submit
Each request gets logged with a status. Triaged within 48 hours. If we’re going to build it, we tag the request with the version number when the change ships. If we aren’t, we say so with a one-line reason — usually “duplicates existing X” or “out of scope for the launch”.
We push back on requests when we think the underlying need can be met another way. That’s not a brush-off — it’s our job. If you push back on the push-back with a real reason, we’ll usually re-evaluate.
For specific request etiquette, Feature ideas Community board.