Shipshot guide
How to recommend an app screenshot workflow responsibly
Recommendations between people shipping apps carry real weight, which is exactly why a careless one costs something. If you are going to tell someone what to use — with or without an affiliate arrangement — a few habits keep the recommendation useful and keep your credibility intact.
Only recommend what you have actually shipped with
There is a large gap between trying a tool and completing a release with it. Problems appear at the update, the localization round, and the export check, none of which a trial reaches. Recommend the tools you have taken through a real submission, and say plainly when your experience is only a trial.
- Distinguish tools you shipped with from tools you merely tried.
- Say which release and what scale your experience covers.
- Avoid recommending on the strength of a feature list you have not exercised.
Disclose any arrangement clearly and early
If you earn something from a referral, say so where the recommendation appears, not in a footnote. Disclosure costs nothing when the recommendation is genuine, and its absence is what makes readers discount everything else you say. Follow the disclosure rules that apply to you rather than the minimum you can get away with.
- State the arrangement in the same place as the recommendation.
- Keep the disclosure plain rather than buried in small print.
- Follow the advertising and disclosure rules applicable in your context.
Describe the fit, not just the verdict
A useful recommendation says who it is for and who it is not. Name the release shape it suits — how many languages, how often it ships, whether a designer is involved — and name the situation where you would suggest something else. A recommendation with no boundaries is an advertisement.
- State the release shape the tool suits well.
- Name at least one situation where you would recommend something different.
- Mention the limitation you found most annoying in real use.
Do not overstate what a tool does
Repeating a capability a tool does not have is the fastest way to burn a recommendation, because the person discovers it during their own release. Be specific about the boundaries — for Shipshot, that it produces finished export files for the supported store targets and that you upload them to the stores yourself.
- Verify each capability you describe rather than repeating marketing copy.
- State clearly where the tool stops and manual work begins.
- Correct a recommendation publicly if a capability changes.
Review checklist
Questions to ask before handoff
Do I need to disclose an affiliate arrangement?
Yes, plainly and in the same place as the recommendation. Follow the advertising and disclosure rules that apply where you are.
Is it fine to recommend a tool I only trialled?
Only if you say so. Most of what matters appears at the update and export stages, which a trial rarely reaches.
What makes a recommendation actually useful?
Naming the release shape it fits, the situation where you would choose differently, and the limitation that annoyed you most.
