# The product launch checklist For indie makers and small teams shipping software: a SaaS, a mobile app, an AI tool, a browser extension, an open source project or a developer tool. It runs from "the product works" to the first month after launch, one item at a time. Every item says why it matters, and says when you can skip it. Pick your launch type and the list gets shorter, not longer. Your ticks are remembered in this browser. ## 1. Before you launch ### 01.1 Write a one-line description that says what it does and for whom Must do · id: `b1` Every directory, store listing and social post asks for this line. Writing it once, properly, saves you writing it badly twenty times under time pressure. ### 01.2 Decide who it is for, in one sentence Must do · id: `b2` If you cannot name the person, you cannot choose the places to launch or the words to use when you get there. ### 01.3 Set your pricing, and have a paid plan from day one if you will charge Must do · id: `b3` Launch traffic is the cheapest attention you will ever get. People who arrive knowing the price convert better than free users you ask for money later. Skip if you are shipping something you have decided will always be free. ### 01.4 Collect early interest (a waitlist or a list of people to tell) Worth doing · id: `b4` A launch with nobody to tell depends entirely on strangers finding you on the day. Even thirty names give day one a floor. Skip if you already reach the audience, for example through an existing product or community. ### 01.5 Pick a launch date and work back from it Must do · id: `b5` Store review, scheduled directory slots and your own asset list all take time you have to book rather than find. A date is what makes the rest of this list finite. ## 2. Product ready ### 02.1 Test signup and onboarding on a fresh account Must do · id: `p1` You have never seen your own product the way a new user does. A clean browser and an email address you have not used before will find the step that is broken. ### 02.2 Install analytics and know the one number you are watching Must do · id: `p2` Launch day produces a lot of noise. Decide in advance which number tells you it worked, so you are not reading traffic charts for a week. Tool that does this: [PostHog](https://posthog.com). Product analytics, funnels and session replay behind one script tag. ### 02.3 Set up error tracking Must do · id: `p3` The first hour of real traffic finds bugs your own testing did not. You want them arriving in a list you can rank, not in support email. Tool that does this: [Sentry](https://sentry.io). Catches the errors your users hit and groups them by how often. ### 02.4 Send transactional email from your own domain (verification, password reset) Must do · id: `p4` Mail from a shared sender lands in spam, and a signup that never receives its verification is a signup lost. Tool that does this: [Resend](https://resend.com). Verifies your domain and sends the signup and reset mail through it. ### 02.5 Test payments end to end, including a refund Must do · Only for: SaaS, AI tool · id: `p5` A failed first charge costs you the customer and the trust. Put one real card through, then refund it, so you have seen both paths. What to check: Put one real card through the whole path a customer takes: choose a plan, pay, receive the receipt, reach the paid features, then get refunded. At every step the plan in your database, the subscription in your payment provider and the access in the app should agree. How to check it: Use your provider's test mode for the failure cases (Stripe publishes test card numbers that decline, ask for authentication or fail after being saved) and live mode with your own card for the final run. Keep the webhook log open while you do it: every event your app relies on should arrive and be handled once. What goes wrong: Webhooks still pointed at a staging URL, checkout that works with test keys but not live ones, receipts sent from a shared address that lands in spam, and a refund that returns the money but leaves the account on the paid plan. Tool that does this: [Stripe](https://stripe.com). Test cards for every failure case, and refunds in two clicks. ### 02.6 Add a privacy policy and terms of service Must do · id: `p6` App stores, many directories and most business buyers will not list you or buy from you without them. ### 02.7 Set usage limits so a launch spike cannot run up your bill Must do · Only for: AI tool · id: `p7` Model calls cost money per request, and one front page placement can multiply your traffic overnight. ## 3. Website ready ### 03.1 HTTPS everywhere, with redirects from the non-www or www version Must do · id: `w1` Two reachable versions of your site split your search signals, and a certificate warning ends the visit before the page loads. What to check: Every version of your address (http and https, with and without www) should end on one canonical https URL in a single redirect. The certificate should be valid, cover both hostnames and renew on its own. How to check it: Run curl -I against each of the four versions and read the status line and the Location header: you want one 301 straight to the canonical address, not a chain. Open the site in a private window and check the browser shows no warning, then look in the developer console for mixed content, which is an http image or script loaded on an https page. What goes wrong: The www version has no certificate, redirects go through two or three hops, a staging domain is still reachable and gets indexed, and a certificate that was set up by hand expires three months after launch. ### 03.2 A title and description on every page Must do · id: `w2` These are the words people read in search results and in shared links. Without them the browser and the search engine guess for you. What to check: Every page has its own title, roughly 50 to 60 characters, that starts with what the page is about, and its own description of about 150 to 160 characters that says what the reader gets. No two pages share either one. How to check it: View the page source, or run a crawler over the site (Screaming Frog is free up to 500 URLs) and sort by title to find duplicates and blanks. Paste a few URLs into a search result preview tool to see where the words get cut off. What goes wrong: Every page titled with only the product name, a single page app that sets the title in JavaScript so some crawlers see the default, and one template description repeated on every page, which search engines ignore and replace with text of their own choosing. ### 03.3 A social share image (Open Graph) that looks right when pasted into chat Must do · id: `w3` Most of your launch links get shared in a chat window. A blank preview reads as broken, a clear one gets opened. What to check: Each page people are likely to share has og:title, og:description and og:image tags. The image is 1200 by 630 pixels, served from an absolute https URL, and still readable when it is shown as a small card. How to check it: Paste the URL into opengraph.xyz to see the card, then into the platforms' own tools, such as the LinkedIn Post Inspector, which also refreshes their cached copy. Then send the link to yourself in the chat apps your users use, because that is where most launch links end up. What goes wrong: A relative image path that works in the browser and fails in every preview, an image behind a login or blocked by robots.txt, text too small to read at card size, and an old preview stuck in a platform's cache after you fixed it. Tool that does this: [opengraph.xyz](https://www.opengraph.xyz). Paste your URL and see the card the way chat will render it. ### 03.4 A favicon Worth doing · id: `w4` It is the only thing identifying your tab among the twenty others someone has open. What to check: A favicon.ico at the root, an SVG or PNG icon linked from the page head, a 180 by 180 apple-touch-icon for phone home screens, and a web manifest with larger icons if people might install the site. How to check it: Look at your tab next to twenty others, add the site to a phone home screen, and search for your product name to see the icon Google shows beside the result. Google asks for a square icon of at least 48 by 48 pixels at a URL that does not change. What goes wrong: The framework's default icon still in place, a detailed logo that turns into a smudge at 16 pixels, and an icon path that redirects or is blocked, so browsers and search engines never pick it up. ### 03.5 A sitemap and robots.txt Worth doing · id: `w5` They tell search engines which pages to read and which to leave alone, which matters most in the weeks when you are first being indexed. What to check: robots.txt at the root allows the pages you want found and names your sitemap. The sitemap lists only canonical URLs that return 200, and nothing that redirects or is marked noindex. How to check it: Open /robots.txt and /sitemap.xml in a browser on the live domain. Submit the sitemap in Google Search Console and Bing Webmaster Tools and check the number of discovered pages matches what you expect. Run the URL Inspection tool on your key pages to confirm Google is allowed to crawl them. What goes wrong: The Disallow: / line from the staging site shipped to production, which quietly keeps the whole site out of search. Sitemaps that list redirecting or duplicate URLs, and a robots.txt that blocks the CSS and JavaScript a search engine needs to render the page. ### 03.6 A useful 404 page Worth doing · id: `w6` Broken links happen at launch more than at any other time, because other people are writing about you. Send those visitors somewhere instead of nowhere. What to check: A URL that does not exist returns an HTTP 404 status, not a 200 with an error message, and shows a page with your navigation and links to the places people most likely wanted. How to check it: Run curl -I against a made up path such as /this-does-not-exist and read the status line, then open the same path in a browser. Single page apps and some hosts serve the home page for every unknown path, which looks fine until search engines find hundreds of copies of it. What goes wrong: Soft 404s: an error page sent with a 200 status, which search engines treat as a thin duplicate page. A bare "Not found" with no way back into the site. Old URLs, or links other people already shared, breaking without a redirect to their new address. ### 03.7 The site loads fast on a phone Must do · id: `w7` Roughly half your launch traffic arrives on a phone, often on a poor connection, and usually from a link someone tapped in passing. What to check: The page meets Google's "good" thresholds for Core Web Vitals on a phone: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1. How to check it: Run PageSpeed Insights on the home page and your main landing pages and read the mobile result first. Its field data, when the site has enough traffic, shows what real visitors got; the lab score is a guide to what to fix. Then load the site on a mid range phone over mobile data and watch what appears first. What goes wrong: A hero image several megabytes large, web fonts that hide the text until they load, analytics and chat widgets that hold up the first paint, and a layout that jumps when a cookie banner or an image without set dimensions arrives. Tool that does this: [PageSpeed Insights](https://pagespeed.web.dev). Runs your page on a phone profile and ranks what to fix first. ### 03.8 Verified in Google Search Console and Bing Webmaster Tools Worth doing · id: `w8` This is how you later find out which queries and which listings actually sent you people. What to check: Google Search Console and Bing Webmaster Tools both have the site verified and the sitemap submitted, and everyone who needs the reports has access, before launch traffic starts. How to check it: Verify the whole domain in Search Console with a DNS TXT record, which covers every subdomain and both protocols at once. Bing Webmaster Tools can import your sites straight from Search Console. After launch, open the page indexing report and read the reason given for each page that is not indexed. What goes wrong: Verification done with a meta tag or an uploaded file that disappears in the next redesign, a property for only one of the four URL variants, and nobody reading the reports, so the queries and crawl errors from launch week go unnoticed. ### 03.9 Make sure an AI assistant can read and recommend your product Worth doing · id: `w10` A growing share of buyers ask an assistant before they open a search engine. If your pages are unreadable to an agent, or your claims are not stated in plain text, you are missing from the answer it gives. What to check: Your key pages deliver their main content in the HTML rather than only after JavaScript runs, robots.txt does not block the AI crawlers you want reading the site, and the page says plainly what the product does, who it is for and what it costs. How to check it: Fetch a page with curl and search the output for your main claims; if they are missing there, many agents will not see them either. Read robots.txt for rules naming GPTBot, ClaudeBot, PerplexityBot or Google-Extended. Then ask a few assistants what your product does and compare the answer with your own page. What goes wrong: A bot protection rule that blocks every automated request, content that only exists in images or in tabs loaded by script, and pricing or features described so vaguely that an assistant has nothing to quote. Tool that does this: [Is It Agent Ready](https://isitagentready.com/). Checks whether an AI agent can reach, read and act on your site, and says what to fix. ### 03.10 A contact address people can actually write to Must do · id: `w9` Directories check that it works, buyers use it, and it is often the only route a serious enquiry has to you. What to check: A real address on your own domain, shown on the site as text, that reaches a person who reads it. If you send mail from the domain, SPF, DKIM and DMARC records are in place so your replies do not land in spam. How to check it: Write to the address from an outside account and reply to that message. Check the domain's MX records and run the sending domain through a checker such as MXToolbox. Make sure someone still receives the mail when the person who set it up is away. What goes wrong: A no-reply address, a contact form that drops messages when its email service fails, an inbox nobody checks, and an address shown only as an image, so neither people nor directories can copy it. ## 4. Launch assets ### 04.1 Logo in square and wide versions Must do · id: `a1` Almost every listing asks for one or the other, and cropping a wide logo into a square while filling in a form looks exactly like what it is. Tool that does this: [SubmitMap](https://submitmap.com/?utm_source=plc&utm_medium=referral&utm_content=a1). Lists the logo and screenshot sizes each platform asks for, so you export once. Learn more: [Asset sizes each platform asks for](https://submitmap.com/?utm_source=plc&utm_medium=referral&utm_content=a1) ### 04.2 Three to five screenshots that show the product doing its job Must do · id: `a2` People decide from screenshots before they read a word. Show the product mid-task with real content, not the empty state. ### 04.3 A short demo video or GIF Worth doing · id: `a3` A fifteen second loop answers "what is this" faster than any paragraph you could write. Skip if your product is a library or a command line tool where a code sample reads better than a video. ### 04.4 A short and a long description, written once and reused everywhere Must do · id: `a4` You will paste these dozens of times. Writing them once keeps the story identical wherever someone meets it. ### 04.5 A first comment explaining why you built it Worth doing · id: `a5` On most launch platforms the maker's first comment is the second thing people read, and it is the only place the reason gets to be personal. ### 04.6 Answers to the five questions people will ask Worth doing · id: `a6` The price, the privacy, the obvious competitor, the missing feature and why not just use the big one. Answer them before they are asked in public. ## 5. Get listed ### 05.1 Find which directories and launch platforms accept your product Must do · id: `g1` Most platforms only take certain kinds of product. Filtering first saves you a week of submissions that were never going to be accepted. Tool that does this: [SubmitMap](https://submitmap.com/scan/?utm_source=plc&utm_medium=referral&utm_content=g1). Scans your product and returns only the platforms that accept it. Learn more: [Scan your product against the platforms that accept it](https://submitmap.com/scan/?utm_source=plc&utm_medium=referral&utm_content=g1) ### 05.2 Leave room in your footer for badges Worth doing · id: `g2` Many directories want a link or a badge back before they will list you. Decide where it goes before you are halfway through a form. Figure: **57%** of the 435 directories we submitted to asked for a badge. (our own submissions, as of September 2026) Learn more: [Directories that do not require a badge](https://submitmap.com/lists/no-badge-required-directories/?utm_source=plc&utm_medium=referral&utm_content=g2) ### 05.3 Expect to create an account on most of them Worth doing · id: `g3` Submissions take longer than the forms suggest. Budget the hours, and use one email address you can search later. Figure: **75%** of our 435 submissions needed an account. (our own submissions, as of September 2026) Tool that does this: [SubmitMap](https://submitmap.com/?utm_source=plc&utm_medium=referral&utm_content=g3). Fills the forms and keeps the accounts and confirmations in one place. Learn more: [Pace and tracking while you submit](https://submitmap.com/guides/pace-and-tracking/?utm_source=plc&utm_medium=referral&utm_content=g3) ### 05.4 Book scheduled launch dates early Must do · id: `g4` The platforms that queue launches are the ones with real audiences. If you wait, your slot lands weeks after the rest of your launch. Figure: **30 days** median wait from submission for scheduled launches. (our own submissions, as of September 2026) Tool that does this: [SubmitMap](https://submitmap.com/?utm_source=plc&utm_medium=referral&utm_content=g4). Shows which platforms queue launches and how far out the next dates are. Learn more: [How weekly leaderboards work](https://submitmap.com/guides/weekly-leaderboards/?utm_source=plc&utm_medium=referral&utm_content=g4) ### 05.5 Don't count on every listing for a backlink Worth doing · id: `g5` Listings are worth doing for the traffic and the social proof. Treat any SEO value as a bonus rather than the reason. Figure: **106 of 150** of our live listings link with dofollow. (our own submissions, as of September 2026) Learn more: [Dofollow and nofollow in directory listings](https://submitmap.com/guides/dofollow-nofollow/?utm_source=plc&utm_medium=referral&utm_content=g5) ### 05.6 Submit to the app stores and registries your product type has Must do · Only for: Mobile app, Browser extension, AI tool, Open source · id: `g6` For some product types the store or the registry is the whole distribution channel, not one listing among many. Mobile app: the App Store and Google Play. Browser extension: the Chrome Web Store. AI tool: the AI directories. Open source: GitHub topics and a tagged release. ## 6. Launch day ### 06.1 Decide whether Product Hunt is right for you Worth doing · id: `d1` It can be the biggest single day of traffic you get, or a day of votes from people who will never buy. The decision is about who your buyer is, not about the platform. Skip if you sell only to enterprise buyers. Learn more: [Should you launch on Product Hunt](https://submitmap.com/guides/should-you-launch-ph/?utm_source=plc&utm_medium=referral&utm_content=d1) ### 06.2 Post a Show HN Worth doing · Only for: Developer tool, Open source · id: `d2` That audience reads code and tries things. It is one of the few places a rough demo can outperform a polished landing page. Learn more: [How to post a Show HN](https://submitmap.com/guides/show-hn/?utm_source=plc&utm_medium=referral&utm_content=d2) ### 06.3 Email everyone who asked to hear about it Must do · id: `d3` These are the only people who have already said yes. They are the cheapest first users you will ever have, and they came before the launch did. ### 06.4 Post on the social accounts where your users already are Must do · id: `d4` One post where your users already read beats five posts on platforms you joined for launch day. ### 06.5 Reply to every comment on launch day Must do · id: `d5` Threads are ranked by activity on most launch platforms, and a maker answering questions in public is the best sales page you have. ## 7. First week after ### 07.1 Email everyone who signed up but did not get started Must do · id: `k1` This is the largest group of people who wanted your product and then hit something. One honest email recovers a surprising share of them. ### 07.2 Talk to five people who used it Must do · id: `k2` Five conversations tell you more about what to fix than a thousand pageviews will. ### 07.3 Ask your happiest users for a testimonial Worth doing · id: `k3` The week after launch is when goodwill is highest and the ask is easiest, and those quotes go on to do a lot of work on your site. ### 07.4 Fix the three most reported problems Must do · id: `k4` Launch week hands you a ranked bug list for free. Shipping the top three, visibly, is what turns visitors into users. ### 07.5 Write a short launch recap with real numbers Worth doing · id: `k5` Real numbers get read and shared, and the post keeps earning attention long after the launch itself is over. Skip if your numbers are commercially sensitive or your buyers are enterprise. ## 8. First month ### 08.1 Find out which listing or post sent your visitors Must do · id: `m1` Without this you repeat all of it next time. With it you know the three places that were worth the effort. Learn more: [Capturing launch traffic in analytics](https://submitmap.com/guides/analytics-capture/?utm_source=plc&utm_medium=referral&utm_content=m1) ### 08.2 Get into "best X tools" roundups and alternatives pages Worth doing · id: `m2` Those pages are read by people already deciding what to buy, and they keep sending visitors for years. Learn more: [Getting into roundups](https://submitmap.com/guides/roundups/?utm_source=plc&utm_medium=referral&utm_content=m2) ### 08.3 Keep submitting at a steady pace instead of all in one day Worth doing · id: `m3` A steady pace spreads your traffic over months, and it stops you from burning a whole week on forms in one sitting. Tool that does this: [SubmitMap](https://submitmap.com/?utm_source=plc&utm_medium=referral&utm_content=m3). Schedules the remaining submissions across weeks instead of one sitting. ## 9. Type specific These items appear only for the launch types you selected. ### 09.1 Follow the store review guidelines before you submit Must do · Only for: Mobile app · id: `t1` A rejection costs days of review time you cannot get back, and your launch date does not move with it. What to check: Read Apple's App Review Guidelines and Google Play's Developer Program Policies against what your app actually does: sign-in, payments, user generated content, data collection and anything that resembles another app. Every feature a reviewer can reach has to work without special setup. How to check it: Walk through the app as a stranger would, with a fresh install and no data. Put a working demo account and short instructions in the review notes: App Store Connect has a field for sign-in details, and Play Console has an app access section. If you sell digital goods, check you use the store's in-app purchase where the rules require it. What goes wrong: The usual rejections are a crash the reviewer hits, a login screen they cannot get past, links to empty or unfinished pages, and payment flows that go around in-app purchase. Each one costs a full review cycle, so a rejection the week before launch usually moves the date. ### 09.2 Screenshots for every required device size Must do · Only for: Mobile app · id: `t2` Both stores refuse the submission outright if a required size is missing. What to check: The App Store needs screenshots for the largest iPhone display size it currently requires, and for iPad if the app runs on iPad; smaller sizes can be scaled from those. Google Play needs at least two phone screenshots and a 1024 by 500 feature graphic, and tablet screenshots if you want to appear well on tablets. How to check it: Open the screenshot section in App Store Connect and the store listing in Play Console before you design anything, and note the exact pixel sizes they list today, because they change with new devices. Export each size from one design file rather than resizing afterwards, and check the text is readable at the size the store shows in search results. What goes wrong: Uploads rejected for being a few pixels off, iPad left on as a supported destination so submission is blocked without iPad screenshots, and screenshots of an older interface that get the listing flagged as misleading. The first three screenshots do most of the selling, so a set that opens on a settings screen wastes them. ### 09.3 Fill in the privacy labels Must do · Only for: Mobile app · id: `t3` Both stores require them, and correcting them later means going back through review. What to check: Apple's App Privacy section and Google Play's Data safety form both ask what data the app collects, whether it is linked to the person, whether it is used for tracking and whether it is shared. That includes what the SDKs you ship collect: analytics, crash reporting, ads and sign-in. How to check it: List every SDK in the build and read its privacy documentation; many publish the answers for both forms. Compare your answers with your privacy policy, which both stores link to, and with the permission prompts the app shows. Apple also expects privacy manifests from many common SDKs, so update them to current versions before you archive the build. What goes wrong: Answers that leave out an SDK's data collection get questioned in review or reported after launch. Declaring tracking you do not do puts a warning on your listing that puts careful buyers off, so answering too broadly has a cost as well. ### 09.4 Run a TestFlight or closed beta Worth doing · Only for: Mobile app · id: `t4` Real devices on real networks find crashes a simulator never will. What to check: Get the build onto real devices you do not own, on real networks, used by people who did not build it. Watch for crashes on launch, sign-in problems, push notifications, sandbox purchases and anything that depends on a slow or dropped connection. How to check it: On iOS, TestFlight lets you add internal testers straight away, while external testers need the build to pass a lighter beta review first. On Android, Play Console has internal, closed and open testing tracks. New personal developer accounts must run a closed test before they can publish to production; at the time of writing that means at least 12 testers opted in for 14 days in a row, so check Play Console for the current rule before you set a date. What goes wrong: Testers who never open the build, a beta that starts too late to fix what it finds, and on Google Play a closed test that falls short of the requirement because testers opted out. Crash reports from a beta are only useful if error tracking is already in the build. ### 09.5 Choose store keywords Worth doing · Only for: Mobile app · id: `t5` Store search is where most app installs begin, and the fields are small enough to be worth thinking about once. What to check: On the App Store, the name and subtitle (30 characters each) and the hidden keyword field (100 characters) decide which searches you appear in. Google Play has no keyword field: it reads the title, the 80 character short description and the full description. How to check it: Write down the words a buyer would type before they know your name, then check the store's search suggestions for each one. On the App Store, separate keywords with commas and no spaces, and do not repeat words already in the name or subtitle. On Google Play, use the main phrases naturally in the short and full descriptions. What goes wrong: Spending the name on a brand nobody searches for yet, repeating the same word across fields, and using competitor names, which the stores can reject. App Store keywords are also tied to a version, so changing them waits for your next submission. ### 09.6 Decide between a trial and a free plan Must do · Only for: SaaS · id: `t6` The two attract different people, and switching after launch annoys the users you already have. What to check: Decide which one you have, how long the trial lasts or what the free plan includes, whether a card is needed to start, and what happens on the last day. Then write it on the pricing page in one sentence. How to check it: Look at how long a new user takes to get real value. If it is minutes or days, a short trial works. If the product gets more useful over weeks, a free plan with a clear limit fits better. Run a test account with a shortened trial so you see the reminder emails and the end of the trial for yourself. What goes wrong: A trial shorter than the time it takes to set the product up, a free plan generous enough that nobody upgrades, and a trial that ends without warning. Asking for a card up front tends to lower signups and not asking tends to lower conversion, so choose on purpose rather than by default. ### 09.7 Handle failed payments Must do · Only for: SaaS · id: `t7` Cards expire constantly. A silent failure looks exactly like churn, and you only find out months later. What to check: Know what happens when a renewal fails: how often the charge is retried, which emails the customer gets, when access is limited, and what happens once the card is updated. Make sure you hear about it too. How to check it: Turn on your provider's automatic retries and failed payment emails (in Stripe these are Smart Retries and the customer emails in the billing settings), and handle invoice.payment_failed and subscription status changes in your app. Test with a card that saves and then declines, on a subscription with a short billing period. What goes wrong: Accounts cut off on the first failed charge, accounts never cut off at all, failed payment emails from a no-reply address the customer ignores, and a card update that does not restart the subscription. In the dashboard, each of these looks like churn. ### 09.8 Put the pricing page on the site Must do · Only for: SaaS · id: `t8` Buyers who cannot find a price assume they cannot afford it, or leave to check a competitor who shows one. What to check: One page, linked from the main navigation, with every plan, its price, the billing period, what is included and where the limits are. Say which currency, whether prices include tax, and what happens at the end of a trial. How to check it: Read the page as someone comparing you with a competitor in the next tab: can they tell which plan they need in under a minute? Check that each button leads straight into checkout for that plan, and that the prices on the page match checkout exactly. What goes wrong: "Contact us" as the only price on a self serve product, limits that only appear at checkout, a monthly price shown for plans billed annually without saying so, and a page that drifts out of date with the plans in the payment provider. ### 09.9 State what the model is and what happens to user data Must do · Only for: AI tool · id: `t9` It is the first question people ask about an AI tool, and the answer decides whether a company can use it at all. ### 09.10 Rate limits and abuse protection Must do · Only for: AI tool · id: `t10` Open endpoints get found. Someone else's automation running on your bill is the usual way that ends. ### 09.11 Justify every permission you request Must do · Only for: Browser extension · id: `t11` Reviewers reject broad permissions, and users read the install prompt even when they read nothing else. ### 09.12 Plan for review time Worth doing · Only for: Browser extension · id: `t12` Store review sits between your launch date and your first user, and it is not under your control. ### 09.13 A README with a quick start Must do · Only for: Open source · id: `t13` The README is the product page. If a working example is not visible in the first screen, people close the tab. ### 09.14 A license Must do · Only for: Open source · id: `t14` Without one, nobody inside a company can legally use your code, however much they like it. ### 09.15 A CONTRIBUTING file Worth doing · Only for: Open source · id: `t15` It is the difference between people filing issues and people sending pull requests. ### 09.16 A first tagged release Worth doing · Only for: Open source · id: `t16` A tag gives people something to pin to and registries something to read. ### 09.17 A quick start that works in five minutes Must do · Only for: Developer tool · id: `t17` Developers evaluate by trying. The clock starts the moment they open your docs, and five minutes is roughly what you get. ### 09.18 Docs for the first real use case Must do · Only for: Developer tool · id: `t18` Reference docs tell people what exists. A worked example tells them whether it fits what they are building. ### 09.19 A way to get an API key without talking to anyone Must do · Only for: Developer tool · id: `t19` A sales call placed between a developer and their first test request loses the developer. ## Questions ### Do I have to do all of it? No. Pick your launch type, read the skip notes, and cut what does not apply. Items marked worth doing can wait until after launch. ### Do I need an account or an email address? No. Reading, ticking, sharing and exporting all work without an account and without an email address, however many items you tick. ### What is saved on your side? No account, no email address and none of your progress. Your ticks, skips and launch types live in this browser only. Page views are counted without cookies or anything stored on your device. ### How do I move my progress to another device? Use Share link. The link carries your ticks and your launch types, and opens the list in the same state anywhere. --- Source: https://productlaunchchecklist.com/