Trust Center
Project discovery is only useful when people can trust the note.
ProjectRadar exists to help readers find useful projects and help builders get a fair look. That only works if coverage is honest, independent, and clear about what it can and cannot promise.
Human publishing decisions
No paid editorial favors
Corrections welcomed
Why Trust Matters
The web has plenty of lists. Trust is the hard part.
The internet is full of sponsored content, fake praise, mass-produced roundups, and pay-to-play lists that are really just ads with nicer formatting. Readers can feel that. Builders can feel it too.
ProjectRadar is meant to be different: useful project discovery, honest project notes, and a process that earns trust over time. Trust is not a badge we get to claim once. It has to be protected on every page, every note, and every correction.
Independence
How ProjectRadar stays independent
A submission is an invitation to consider a project, not a purchase order for coverage. Founders can share context, links, and access details, but publication judgment stays with ProjectRadar.
- Submitting a project does not buy coverage.
- Money does not influence project notes, optional discovery context, category eligibility, or conclusions.
- Founders cannot purchase a stronger context label or category position.
- Coverage decisions stay independent, even when a founder provides temporary access.
- Coverage decisions, public notes, and optional discovery context are made by humans.
Standards in practice
Tools support research
Research tools may help organize public information, positioning, discoverability, security, and launch-readiness notes. They do not make publication decisions or approve project notes.
Discovery context needs human approval
Discovery context considers public-facing details such as clarity, usefulness, audience fit, readiness, trust cues, design, discoverability, and project status. It is not a promise of traffic, search visibility, revenue, safety, quality, or success.
Submitted links may be screened
URLs may be checked for malware, phishing, spam, private-network targets, or abuse. A clean scan is not a guarantee that a site is safe.
Private details stay private
Submission notes, emails, access instructions, and private queue records are used for intake and should not be copied into public notes.
Sponsored visibility, if offered, will be clearly labeled and kept separate from editorial notes. Paid links will use appropriate attributes such as rel="sponsored" or rel="nofollow" where required.
What We Believe
The principles behind the notes
Readers first
A project note should help someone decide whether a project is useful for them, not simply repeat a founder's pitch.
Builders deserve fairness
Launching is hard. We try to describe projects honestly, with enough context for readers and enough respect for the people building.
Useful products deserve visibility
ProjectRadar is especially interested in smaller tools, apps, websites, games, and utilities that might otherwise be missed.
Transparency beats hype
We would rather explain what we know, what we checked, and what still needs a human look than pretend every answer is certain.
Corrections should be easy
If a factual detail is wrong or outdated, founders should have a clear path to ask for a correction.
Honest context is valuable
A fair project note can include what stands out and practical next questions without turning into a takedown.
Corrections
How we handle corrections
Mistakes can happen. Products change, pages move, pricing shifts, and early launches evolve quickly. Pretending otherwise would not make ProjectRadar more trustworthy.
Founders can contact ProjectRadar when a published project note includes outdated or inaccurate factual information. Factual errors should be corrected. Products that materially change can be revisited. Independent takes may remain unchanged, but accuracy matters.
Correction path
Tell us what is wrong
Share the best source or context
We check the factual issue
We update the page when a correction is warranted
What We Do Not Do
Clear boundaries make the site easier to trust
- Sell category position
- Sell discovery context labels
- Guarantee backlinks
- Guarantee traffic
- Guarantee publication
- Accept payment for favorable notes
- Create fake founder stories
- Publish fabricated notes
Project notes may include links when those links help readers evaluate a project. That does not mean ProjectRadar guarantees backlinks, search visibility, referral traffic, customers, publication, or a favorable note.
Builders And Readers
Built for builders, trusted by readers
Many ProjectRadar submissions come from indie founders, solo developers, creators, teachers, hobbyists, and small teams. Some projects are polished. Some are early. Some are useful in a narrow, specific way.
Launching anything online takes effort. ProjectRadar respects that effort, but the note still has to serve readers first. Honest coverage helps both sides: readers get clearer discovery, and builders get a more useful context than empty praise.
Start here
Want to see the standards in action?
Submit a project for a fair look, read the notes already live, or walk through the project note process before you send anything in.