why we publish every rejection reason
every submission we reject gets one of five reasons back to the seller, and we publish the aggregate. transparency about what fails is the only way the bar stays credible.
every listing we reject gets a reason back, and that reason is always one of the same five checks: functional, source available, proof of substance, honest scope, or engineered, not generated. we don't invent a new reason case by case.
functional
runs from a clean install. we do that install ourselves, not from a screen recording the seller sends us.
source available
repo access on request, with a commit history we can actually read.
proof of substance
sustained use, not one transaction. a small mrr that holds, a user count over time, or a finished audit.
honest scope
the listing matches the repo, and says plainly what the product does not do.
engineered, not generated
real engineered work, not something prompted into existence. we read the commit history and we can tell.
a rejection reason is not a verdict. it's the one thing a seller needs to fix before trying again.
publishing which check a listing failed on, even in aggregate, means the bar can't quietly move without anyone noticing. if one check starts failing everything, that's on us to explain, not to hide.
written by solstead team