The 90‑Minute Launch Sprint: Ship a Store‑First Playable, Screenshots, and JSON‑LD
Written by AppWispr editorial
Return to blogTHE 90‑MINUTE LAUNCH SPRINT: SHIP A STORE‑FIRST PLAYABLE, SCREENSHOTS, AND JSON‑LD
Founders and solo makers: you don’t need a polished product to show product value. In a single 90‑minute, timeboxed sprint you can produce an installless playable demo (HTML5), a store‑first screenshot storyboard for Apple and Google, and a compact JSON‑LD package that makes your feature machine‑readable and AI‑citable. This recipe focuses on speed, handoffs you can give to contractors, and the conversion checks to know whether your assets are working.
Section 1
Why a 90‑minute, store‑first sprint works
A store‑first sprint forces a single decision: create artifacts that sell the core value immediately. App stores reward clarity in the first 1–3 screenshots and in the listing metadata; a tight playable demo does the heavy lifting of reducing uncertainty without requiring an install.
This sprint is deliberately timeboxed to avoid feature creep. You’re not shipping a finished product — you’re creating three buyer signals: an interactive, installless demo; a 3–5 frame screenshot storyboard that communicates benefit-first use cases; and a small JSON‑LD manifest that surfaces the feature to crawlers and AI agents.
- Focus on one feature or first‑time user flow.
- Ship only what a user needs to decide to install (or share).
- Produce contractor‑ready assets and a JSON‑LD file that describe the feature and screenshots.
Section 2
Minute‑by‑minute 90‑minute plan (what to do when)
0–10 min: Sprint kickoff. Define the single flow your playable must demonstrate (e.g., 30‑second core task). List exact screens to capture for screenshots — headline + visual for each, 3–5 frames total.
10–40 min: Build the playable stub. Use a single HTML index file with lightweight JS and a few assets (sprite or PNG) so it runs in a browser without install. Keep interactions shallow: a 15–30 second guided flow that ends with a CTA to install or open the listing.
40–65 min: Compose store screenshots. Export clean device‑framed screenshots for the primary store sizes (Apple: current iPhone display class; Google: phone + feature graphic). Create text overlays that answer “What it does” and “Why it matters” in one line each.
65–85 min: Write minimal JSON‑LD and metadata. Add a compact softwareApplication JSON‑LD snippet describing the app, its main feature, URLs to the playable and screenshots, and an author/publisher block so crawlers and AI tools can cite the feature easily. Validate quickly with a structured data tester or linter.
- Deliverable checklist by 90 minutes: playable/index.html, 3–5 store‑ready screenshots, feature graphic (1024×500), JSON‑LD file.
- Keep assets small (fast load) and names explicit for contractor handoffs (e.g., hero_screenshot_01@2x.png).
- Use browser tools to record the playable flow for a preview video if needed.
Section 3
Concrete assets to hand contractors (templates and copy)
Playable: hand off a single index.html with comments. Include a short README: entry point, assets folder, success state, and the exact CTA text to show. Contractors should not need to build game logic — give them a tiny mock of the UI and a simple click sequence.
Screenshots: supply the designer with the storyboard (frame 1 headline, frame 2 benefit, frame 3 social proof or CTA), raw device screenshots, and exact export sizes. For Apple, target the primary iPhone display class the App Store accepts; for Google, prepare phone screenshots plus a feature graphic at 1024×500. Provide final copy as short, scannable headlines (6–10 words) and a 1‑line subhead.
- README for playable: required assets, max bundle size, fallback image, CTA URL.
- Screenshot export names and sizes: hero_1024x500_feature.png, phone_1_1242x2688.png (or store canonical size), etc.
- Provide localization placeholders if you plan to test multiple markets.
Sources used in this section
Section 4
JSON‑LD: what to include and a minimal example
Why JSON‑LD: a small JSON‑LD softwareApplication object makes your feature discoverable to search engines and AI agents that can cite an exact canonical description. Keep it minimal: name, description, url (playable), screenshot array, applicationCategory, offers (if relevant), publisher, and datePublished.
Validation: paste your JSON‑LD into a structured data tester (or run a quick linter). Host the JSON‑LD at a predictable path (e.g., /.well‑known/appwispr-feature.jsonld or alongside the playable) and link it from the playable HTML <head> with a script tag so crawlers find it.
- Include at least 1 playable URL and 2–3 screenshot URLs in the screenshot array.
- Use ISO 8601 dates for datePublished and a stable @id (canonical URL).
- Keep the JSON‑LD file <10KB and served with correct Content‑Type: application/ld+json.
Sources used in this section
Section 5
Quick conversion checks and next steps after 90 minutes
Conversion checkpoints: measure click‑through from the playable to the store listing or mailing list, time on playable, and an early A/B: variant A with benefit headline vs variant B with social proof headline. If you have analytics in the playable, 200–500 impressions should reveal directionality.
After the sprint: iterate assets based on one metric at a time (CTA wording, first screenshot headline, playable length). Move the playable into a stable URL you control and version the JSON‑LD if you change the feature text. Use what you learned to brief a designer for higher fidelity screenshots and to expand localization.
- Primary metrics: playable CTAs → store listing clicks, screenshot CTR on listing page, and install conversion if possible.
- If the playable has low engagement, shorten the flow or make the first action immediately gratifying.
- Document every change to the JSON‑LD and keep the published file URL stable for AI citations.
Sources used in this section
FAQ
Common follow-up questions
Do app stores allow a playable demo linked from the store listing?
App stores do not host arbitrary HTML playables inside listing assets, but you can host an installless playable on a public URL and link to it from marketing fields or the developer website. The playable should not misrepresent the product experience and must follow store policies for promotional content. Use the playable URL in JSON‑LD and on your marketing site rather than trying to embed HTML inside store metadata.
What screenshot sizes are absolutely required to publish?
Apple requires screenshots for the primary device display class used by App Store Connect; in practice provide the App Store's canonical iPhone screenshot size. Google Play requires at least phone screenshots and a feature graphic (1024×500). Always check the store consoles for exact, current dimension requirements before final export.
Will JSON‑LD make my feature 'AI‑citable' immediately?
JSON‑LD helps machines find a canonical description and assets, which increases the chance automated systems and AI agents can cite the feature accurately. It’s not a guarantee — properly hosted, valid JSON‑LD linked from your playable and site increases discoverability and citation quality.
How do I keep the playable fast and small?
Limit assets to a few sprites or PNGs, avoid large audio/video, and keep the JS minimal. Use a single index.html with preloaded assets and a fallback image. Aim for under 200–400KB for quick loads on mobile connections in the initial sprint.
Sources
Research used in this article
Each generated article keeps its own linked source list so the underlying reporting is visible and easy to verify.
Apple Developer
Screenshot specifications - App information - Reference - App Store Connect - Help - Apple Developer
https://developer.apple.com/help/app-store-connect/reference/app-information/screenshot-specifications/
Apple Developer
Upload app previews and screenshots - Manage app information - App Store Connect - Help - Apple Developer
https://developer.apple.com/help/app-store-connect/manage-app-information/upload-app-previews-and-screenshots
AppsTemple
Feature Graphic Size for Play Store: 1024×500 Rules (2026)
https://www.appstemple.com/guides/feature-graphic-play-store/
Unity / Unity Ads (guide)
Playable Ads on Unity (Playable guide)
https://habrastorage.org/getpro/freelansim/allfiles/7/74/74195/UnityAds_Playable_guide_v1.0.pdf
Schema.org
Schema.org
https://schema.org/
SchemaApp
Schema Markup Checklist for marketers (examples and best practices)
https://www.schemaapp.com/wp-content/uploads/2024/05/Schema-Markup-Checklist-for-marketers.pdf
AppSceno
Google Play Store Screenshot Sizes & Requirements 2026 — Complete Guide
https://appsceno.com/sizes/google-play
Screenshots are one of the most under-tested parts of a product page — community notes
https://www.reddit.com/r/AppStoreOptimization/comments/1ua5hcj/screenshots_are_one_of_the_most_undertested_parts/
Next step
Turn the idea into a build-ready plan.
AppWispr takes the research and packages it into a product brief, mockups, screenshots, and launch copy you can use right away.