How Project Notes Work
How a submission becomes a Project Note.
A Project Note introduces readers to a project: what it does, who might use it, and where to try it.
It brings together information from the builder and the public project page, with useful details and questions to check before trying it.
A useful Note gives readers clear details, with factual support and honest limits. Submitting does not guarantee publication.
What a project note is
An introduction readers can use.
Readers can use the note to decide whether to explore a project. Builders can share the page with people who want to learn more about it.
A note can include
- What the builder says they made
- What stands out from a practical first look
- Who it might be useful for
- What readers should check before trying it
- Where to try the official project
How builders can use it
- Link it from your website or changelog
- Share it with early users, testers, or launch followers
- Include it in launch posts with your own context
- Use the badge if the project is eligible for one
- Quote the short take with a link back to the full page
What happens after you submit
From submission to a possible Project Note.
The Project Note Process starts with what you share. We check the submission and consider whether a Note would help someone understand the project.
Send the basics
Tell us what you made, where people can find it, and who it might help. Contact details and any private access instructions stay private.
We check the submission
We check the submission against the project's public pages and consider whether a Project Note would be useful to readers. We may ask for more context or check the submitted link for spam, phishing, or abuse.
A possible Project Note
If we cover the project, its Note explains what it does, who it may help, what stands out, and where to try the official project. Factual claims should have support, and important limits stay beside them. Submission does not guarantee publication.
Updates and corrections
Products change. Builders and readers can ask us to check a detail that is wrong or out of date. Factual corrections are free.
How a note is checked
We compare factual details with the information the builder provides and the project's public pages. If something is unclear, the Note should say so. That helps readers decide what to check for themselves.See how Discovery Context works →
Builder-friendly, reader-focused
Many projects we look at come from indie builders, solo founders, teachers, creators, developers, and small teams. We are not here to tear down unfinished work. We are here to help readers find useful products and give builders clear, constructive public pages when coverage makes sense.
What we do not promise
The limits of a Project Note.
ProjectRadar does not test every feature, does not run private code, and does not verify every claim. It is not a security audit. It is not a certification, expert endorsement, purchasable category position, or guarantee that a project is production-ready.
A Project Note can include a link when it helps readers evaluate a project. That link does not guarantee search performance, referral traffic, customers, approval, safety, or a positive conclusion.
Fairness and corrections
We try to be fair, and we fix facts.
We care about useful products. Early projects can be messy, incomplete, or changing fast. Project Notes should be honest without being careless.
If a published project note has outdated or inaccurate factual information, we welcome correction requests. We correct factual mistakes, though ProjectRadar may retain its original editorial conclusion.
Builder submissions
Ready to show us what you are building?
Send the project, the clearest URL, and the context that would help us understand it fairly. Apps, games, programs, websites, SaaS products, AI tools, utilities, calculators, and other useful indie projects are welcome.