How Project Notes Work
ProjectRadar publishes structured discovery notes, not leaderboards, purchasable notes, or approval badges.
When someone submits a project, the goal is to turn that submission into a clear public page people can quickly understand.
A project note is a public discovery profile: what the builder made, who it may help, what stands out, what to check next, and where to find the official project.
Some of the workflow is assisted by automation, but publishing is not automatic. A person still reviews the submission, edits the wording, checks that the page makes sense, and decides whether it should go live.
What a project note is
A public project note, not a product ruling.
For builders, the value is a clean page you can point people to when they want an outside read on the project. For readers, the value is speed: they can quickly understand what the project is, why it might be useful, what to check first, and where to try the official project.
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
A clear path from submission to possible note.
The Project Note Process is intentionally simple. We want enough structure to be fair and consistent, but not so much process that a small builder feels like they are pitching a committee.
Submission received
If you send us a project, we first make sure the basics are there: what the builder made, where people can see it, who it might be useful for, and any private context the builder chose to share.
Basic fit and safety check
We check that the submission is readable, reachable, and relevant for ProjectRadar readers. Submitted URLs may be screened for malware, phishing, spam, or abuse before a human looks closer.
First draft preparation
Automation can help organize the submitted information, catch missing details, and prepare a first draft so project notes stay consistent.
Human edit
A person reviews the submission, edits the wording, checks that the page makes sense, and keeps the note grounded in what readers can understand.
Publication decision
Publishing is not automatic. A human decides whether the project should go live as a public ProjectRadar note.
Public project note
If we publish, the project note is written for readers first: what the project does, who it may help, what stands out, and where to try the official project.
Updates and corrections
Products change. If something is outdated or factually wrong, builders can request a correction and we will check it.
Humans make the final call
Research tools can help organize submitted information, prepare a first draft, catch missing details, and keep project pages consistent. They cannot approve a project note, write the final public wording, add a public discovery context label, or decide whether a project fits the site. Those calls stay human because judgment, context, and fairness matter.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
Independent publication matters more than easy promises.
ProjectRadar does not test every feature, does not run private code, does not verify every claim, or act as 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 to a project when that link helps readers evaluate the product. That does not mean we 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, but we also know 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. Independent takes may still remain unchanged, but factual fixes matter.
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.