how to iterate after a rejection
most sellers who get rejected don't come back. the ones who do either don't understand what failed, or they understand it but can't prove they fixed it. here's what reapplication actually looks like.
rejection isn't a verdict. it's a map. check three failed (proof of substance)? that means you need sustained usage data, a verified user count, or an audit. check five (engineered not generated)? show us a commit history that proves it. the five checks aren't random, and they aren't gatekeeping disguised as quality. they're each fixable once you understand what we're actually checking for.
the sellers who reapply successfully do one thing differently: they show, not tell. a seller who failed check one (functional) doesn't just resubmit and say “it works now.” they test it on a clean machine, screenshot it running, and include that in the resubmission notes. App Store, HubSpot Marketplace, AWS Marketplace all flag the same thing. specific, testable proof is faster than assertions.
test as the reviewer would test. most rejection cycles get stuck because the seller fixed the problem in their local environment but didn't verify it in the exact way a reviewer would run it. for check one, that means install from scratch, not restart your running instance. for check two, that means a repo with readable commit history, not a summary. for check three, that means data that's existed long enough to be real, not backfilled numbers from last month. test the path. confirm it yourself. then document what you tested.
know the difference between gatekeeping and verification. some rejections are about fit: the product is too small, too niche, or solstead just isn't the right marketplace for it. that's portable across markets but it won't change if you iterate. other rejections are about evidence: we couldn't verify something you claimed. that will follow you everywhere until you fix it. if we rejected you because we couldn't verify proof of substance, fixing that proof is worth a reapplication. if we rejected you because the product is genuinely outside our scope, iterating the product probably won't change the outcome.
if we rejected you because we couldn't verify something you claimed, that will follow you everywhere until you fix it.
identify the check
which of the five failed. if you don't have that reason, ask.
read what it measures
understand what that check actually looks for. if it's still unclear, say so.
build specific evidence
not “i fixed it,” but the demo running, the repo with commit history visible, or the data that shows sustained use over time.
test the exact path
if you're resubmitting check one, install from scratch and confirm it runs. if you're resubmitting check three, pull the real data and confirm it's sustained.
document the test
include what you tested, how you tested it, and what it proves.
rejection is temporary. most sellers don't come back. the ones who do, and who bring specific evidence, usually pass.
written by solstead team