how to prepare your product before you list
most rejections are predictable. a seller who spends a month preparing catches nearly everything a reviewer would flag.
you built something real. it has users, it runs, and you’re ready to sell it. the gap between “I think this is ready” and “this will actually pass review” is smaller than most sellers expect. but it exists, and the sellers who close it before submitting are the ones who clear on the first pass.
we review every listing against the same five checks. most failures land on three of them: functional, proof of substance, and engineered not generated. all three are fixable before you ever hit submit.
start with the install. download your own codebase fresh, onto a machine that has never run it. follow your own readme. if any step assumes context you forgot to write down, fix it now. a buyer expects to get from “I received access” to “the app is running” in under fifteen minutes. you should be able to do it in five. if you can’t, neither can they, and check one fails.
proof of substance trips up sellers who have the data but haven’t organized it. if you have paying users, export a list with dates and amounts going back six to twelve months. if you don’t have six months yet, get to three first. what won’t pass: a spike of transactions from last month added to make the graph look better. sustained means it existed before you decided to sell. we can tell the difference, and so can buyers.
your commit history is the story, and the story matters more than the code. one commit with ten thousand lines is a problem. a readable progression of mistakes, experiments, and fixes is proof. if you’ve been working in private, make the repo visible now. document the decisions that shaped the product. “rewrote auth after the first version had a session leak” is credible. “somehow this just works” is not.
documentation is the difference between a completed sale and an escrow refund. write a readme that covers what the product does, how to run it, and what it’s not good at. document your deployment process and any manual steps that happen on a schedule. a buyer who has to reverse-engineer your process from the code will spend the handoff window doing that instead of confirming the product works. that’s how refunds happen.
a seller who prepares like a buyer will test it is a seller who passes on the first submission.
clean up the repo before you open it. credentials hardcoded in a config file, an api key in a commit message, comments that read like a personal journal. keep the history, just make sure it reads like something you’d show a colleague who’s about to take over.
none of this is extra work. clean installs, documented operations, organized financials. these are the same practices that make a product easier to run while you still own it. the sellers who prepare well aren’t just passing review. they’re proving the product can survive without them.
written by solstead team