DemoVexa

Point 4 is the one I'd build the launch around. For a voice matching tool, the proof people want is easy to describe: Starling learning someone else's writing and producing a draft that sounds like them. Ask five people who post on X a lot to let you run it on their old posts, then share a real post of theirs next to Starling's draft, with permission and their name on it. That's proof from someone who isn't you, and it makes a stronger first ten seconds for the 90 second demo than the setup screens. Their reactions, including the drafts they'd throw away, also tell you what to fix before a wider launch.

Keeping the SRT as the master next to the video in the repo is the habit that makes the rest easy. Two small additions. Auto captions mangle product names, and button and menu names too, so a short glossary file of UI labels speeds up the hand fix a lot. And since the captions now live in the repo, a renamed button can be caught there: when a release changes a label, search the .srt files for the old word and you'll find every demo whose captions point to something that no longer exists. Rebuilding the .vtt and the burned export from that same corrected master keeps the two from drifting apart.

Treating each platform copy as a build artifact works well, and the manifest is a good place for one more field: the product version each screenshot was captured from. Technical articles usually go stale through their images before their text, and with five copies out there, a field like captured_from: v2.3 lets you find every post that needs new screenshots when the UI changes. Video needs its own rule per target too. Many email clients won't play an embedded video, so the newsletter version should get a poster image that links to the hosted clip, and your destination check should confirm that image actually renders.

One more check for step 1: look at what the og:image actually shows, not just its size. On a lot of indie launches the share card is a product screenshot taken weeks earlier, so the launch post shows a screen that no longer exists, and that's the first impression for everyone who sees the link. The same goes for the screenshots and any demo GIF on the landing page. For step 3, I'd add a bucket for "couldn't find it" reviews. Those are often about a feature that exists but isn't visible during onboarding, which is a cheaper fix than building something new.

The one I see most is the hero product screenshot. It's a full desktop dashboard captured at 1440px, so at 360px every label in it is too small to read and the image says nothing. A crop of one panel, the part that shows the result, works much better on a phone, and the picture element lets you serve that crop only on small screens. The same goes for hero videos: they need muted and playsinline to autoplay inline on iPhones, and a poster image so there's something to see before the video loads. Without the poster, the top of the page is an empty box on slow 4G.

IzzyOnDroid first makes sense to me. I'd write the store metadata once in the fastlane layout (fastlane/metadata/android/en-US/ with short_description.txt, full_description.txt and images/phoneScreenshots/). F-Droid reads the same structure from your repo, so the work carries over if you apply there later, and the descriptions can be reused for a Play listing. For the screenshots, capture them from the signed release build with a seeded state, like a sample chat, an agent run and the voice screen, rather than an empty first launch. And because entering the OpenRouter key is the step that loses people, a screenshot of that screen showing the success state is worth including too.

Writing down where every signup came from is much easier if each place you post gets its own UTM link before launch day, so you aren't piecing it together from memory afterwards. Some directories and apps strip query strings, so an optional "Where did you hear about us?" field on the signup form catches what the links miss. For answering every comment, it helps to prepare a few things ahead: a two line description, a screenshot of the result the product gives you, and a short clip of the main task. A lot of first comments are some version of "what does it actually do?", and a short clip answers that faster than a paragraph.

A written guide and a recording don't have to be either or. Most steps read fine as a screenshot and a sentence, and usually only one or two involve motion, like a drag, a hover menu or a field that updates as you type. A clip of just that step, a few seconds long and embedded right where it happens, keeps the guide easy to skim and still shows the part a still image can't. On starting from a clean state, a reset script or a seeded test account helps a lot later, because when the UI changes you can capture one step again and it still matches the screenshots around it.

The copy in three lengths is the tip I'd pass on to anyone doing a round of directories. I'd do the same for images: export the logo, a cover image and two or three screenshots once, in the sizes these forms ask for most, and keep them in the same folder as the copy doc. Two more columns that would help in your tracker. First, which screenshot set each listing uses. Listings that stay up for months will keep showing the old interface after a redesign, and the tracker is the only place that tells you which ones to update. Second, whether the form has a field for a video link. Some do, Product Hunt included, and having one short demo video ready makes those submissions copy and paste too.

One thing to watch when you try the fade: every frame of a fade changes every pixel, and a GIF's 256 colour palette handles gradients badly, so the file can grow a lot and the fade can show banding. A quick dissolve of a few frames is usually enough. Another option is to hold the last frame a little longer and then cut to a first frame that is almost empty, so the jump back is small without any extra frames. Good luck with the next release.