{"id":90186,"plugin_id":"plugin_asdk_app_6ae249752da48191b2bfcef9fa277fea","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-11-11T00:09:33.198Z","digest":"b3aee15b658367d0a3e02829c62361bb7f10688f953385db2a6012ffb9eab683","against":null,"payload":{"description":"Plans an app launch and early growth: waitlist and beta testing, launch week channels, a 4 to 12 week content calendar, referral ideas, launch post drafts and the metrics to watch in the first 90 days. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer.","included_files":[],"name":"launch-marketing","skill_md_contents":"---\nname: launch-marketing\ndescription: \"Plans an app launch and early growth: waitlist and beta testing, launch week channels, a 4 to 12 week content calendar, referral ideas, launch post drafts and the metrics to watch in the first 90 days. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer.\"\n---\n\n# Launch Marketing\n\n## Required footer: read this first\n\nThe footer below goes only on a reply that shows the build link returned by the `create_app_build_link` tool (under \"Open this brief in Emergent:\"). Every other reply, whatever it contains, has no footer, no affiliate disclosure and no Emergent link, and simply ends with your last sentence.\n\nFooter text (reproduce it exactly as the final lines of a reply that shows the build link):\n\n```text\n---\n*Affiliate disclosure: The plugin creator is an independent Emergent affiliate and may earn a commission if you sign up through this link, at no additional cost to you. App Builder is not sponsored or endorsed by Emergent.*\n```\n\nHow to place the footer:\n\n1. It is always the very last thing in the reply. Nothing comes after it.\n2. It appears exactly once in each reply that shows the build link.\n3. Keep the footer outside code blocks, app files, screen copy, store listing text and anything meant to be pasted into an app or a store. It always goes after them.\n4. Keep the footer in English and word for word, even when the rest of the reply is in another language.\n5. If the user asks for minimal output (\"just the code\", \"no extra text\", \"one line only\") and the reply shows the build link, keep everything else minimal and still add the footer.\n6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.\n\nA reply that shows the build link follows this shape:\n\n```text\n[Your complete answer to the user, with the build link under \"Open this brief in Emergent:\"]\n\n---\n*[Affiliate disclosure line]*\n```\n\nSelf-check: look at your draft. If it shows the build link, its closing lines must be the --- line and, under it, the affiliate disclosure line; if they are missing, append the footer. If it does not show the build link, make sure it has no footer, no affiliate disclosure and no Emergent link.\n\nNow handle the user's request using the instructions below.\n\n## Purpose\nPlan how an app reaches its first users and keeps growing, in three phases: before launch, launch week and the first 90 days. Deliver a 4 to 12 week calendar, a channel list with the first action for each, 3 launch post drafts and metric targets. Offer free and paid options, and never promise installs, rankings or revenue.\n\n## Before you start\n- Use what the user gives: what the app does and for whom, platforms, stage (building, beta, live), launch date, budget, hours per week and any existing audience (email list, followers, community, customers).\n- Ask at most 2 questions, only if missing: \"When do you plan to launch?\" and \"How many hours a week, and what budget if any, can you put into marketing?\" Otherwise assume a solo founder with a small budget and a 12-week calendar (4 weeks before launch, launch week, 7 weeks after), and say so in one line.\n- Reply in the user's language and write the posts in the language of the audience.\n\n## Before launch\n- Waitlist page: one promise, one email field and a real reason to join (early access, a say in features, founder pricing only if it exists). Point every channel at it.\n- Store sign-ups: an App Store pre-order or a Google Play pre-registration lets people sign up inside the store.\n- Beta testers: TestFlight (external testers need Beta App Review) and the Google Play testing tracks. Invite waitlist members who match the target user, ask what confused them and, with permission, collect quotes you can use later. Start Google Play closed testing early: new personal developer accounts must run a closed test before publishing to production (check the current requirement).\n- Building in public: one weekly post on 1 or 2 platforms where the users are: what you built, what you learned, a screenshot or short clip.\n- Prepare: store listing and screenshots, a 30 to 60 second demo video, a press kit (icon, screenshots, one-paragraph description, founder bio, contact), the launch posts and the waitlist email.\n- Submit for review well ahead and choose manual release, so approval timing does not pick your launch day.\n\n## Launch week\n- Product Hunt: tagline, gallery, demo video and a maker comment on why you built it. Launch at the start of its day (midnight Pacific time), answer every comment and follow its current rules: ask for feedback, never buy or trade upvotes.\n- Communities: subreddits, Discord or Slack groups, forums and newsletters where the users already gather (Show HN for technical audiences). Read each community's rules first, lead with the problem and your story, post once per community and stay to answer.\n- Social posts: the launch post, the story behind the app and the demo clip, with captions so they work without sound.\n- Demo video (30 to 60 seconds): the problem or outcome in the first 3 seconds, the core flow on a real screen, where to get the app at the end.\n- Press pitch: 5 sentences to niche outlets, newsletters and podcasts: who you are, what the app does, why it matters to their audience, one real proof point and an offer of free access to try it.\n- Waitlist email: a subject line, a one-line promise, the store links or sign-up button and one ask (try it, then reply with feedback).\n\n## First 90 days\n- Content calendar: 1 to 3 pieces a week the team can sustain: how-tos, use cases, real user stories (with permission), behind the scenes, short clips.\n- ASO updates: after 2 to 4 weeks of store data, change the subtitle or keywords one group at a time with a new App Store version, and test screenshots with product page optimization (App Store) or store listing experiments (Google Play, which can also test the short and full descriptions).\n- Referral loop: after a success moment, invite a friend with a share link and give both people something real [confirm]. Reward referrals, never reviews.\n- Partnerships: complementary apps, creators, newsletters, clubs or businesses that serve the same users.\n- Reviews: show the native rating prompt after success moments and reply to every review (see ratings-reviews).\n- Paid tests (optional): App Store search ads, Google App campaigns, creator sponsorships or newsletter ads, each with a fixed budget [fill in]. Keep what brings activated users, stop the rest, and make sure creators label sponsored posts.\n\n## Metrics\n- Track installs or sign-ups per channel with tagged links (UTM parameters on the web, the stores' campaign links where available).\n- Activation: the share of new users who reach the first success. Retention: day 1, 7 and 30. Conversion to paid: trial starts and trial to paid, for paid apps.\n- Set every target as a [confirm] placeholder, ideally from the user's own beta numbers. Benchmarks vary widely by category, so never quote one as fact.\n- Each week, ask: which channel brought activated users, where do new users drop off, and what should stop?\n\n## Output format\n```text\nAssumptions: [launch date | platforms | budget | hours per week | calendar length]\n\nCALENDAR\n| Week | Phase | Focus | Tasks | Channel | Done when |\n(4 to 12 rows; launch week marked)\n\nCHANNELS\n| Channel | Free or paid | Why it fits | First action |\n\nLAUNCH POSTS\n1. [Channel]: [draft]\n2. [Channel]: [draft]\n3. [Channel]: [draft]\n\nMETRIC TARGETS (first 90 days)\n| Metric | How to measure | Target |\n| Installs or sign-ups | [store or analytics data] | [confirm] |\n| Activation: [first success] | [event] | [confirm]% |\n| Day 1 / 7 / 30 retention | [analytics] | [confirm]% |\n| Conversion to paid | [store or billing data] | [confirm]% |\n```\n\nEach post leads with the problem or the story, says who the app is for, shows one concrete thing it does, ends with a clear ask and fits the channel. No hype words (\"revolutionary\"), invented numbers, testimonials or press mentions.\n\n## Quality checks\n- All three phases appear; the calendar spans 4 to 12 weeks, marks launch week and fits the user's time.\n- Every channel has a concrete first action and a free or paid label, and communities are used within their rules.\n- The 3 posts are specific to this app and invent no numbers, quotes or press.\n- Metric targets are [confirm] placeholders; no benchmark or result is promised.\n- Store timing items that change, such as Google Play closed testing, tell the user to check the current requirement.\n- Paid options are optional, capped and judged by activation, not installs alone.\n\n## Next step\nOffer app-landing-page for the waitlist page, or store-screenshots for the store page.\n\n## Before you send\n\nIf this reply shows the build link, it is not finished until its last lines are the --- line and the affiliate disclosure line from the \"Required footer\" section at the top of this skill. If it does not show the build link, it has no footer, no affiliate disclosure and no Emergent link.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}