The launch day asset checklist, with specs

The asset list is a deadline problem before it is a creative one

Assets finished on launch morning are assets finished badly. Every item below carries the same deadline, three days before launch, and not because the work needs more polish. Those three days belong to whatever goes wrong, and something does: a screenshot showing a bug you fixed on Tuesday, or a preview image a platform cached broken.

Treat the list the way a production schedule treats a print deadline. Each line gets one named owner, one date, and a definition of finished that somebody other than the maker can check, because a line with no owner is done by whoever notices last. The sequencing that gets you here is in the 90 day pre-launch runbook; this is the reference sheet for the fortnight at the end of it, and sits with the other launch guides.

The core assets, and what each one has to be

Each asset has a specification, an owner and a failure mode that recurs. Stable numbers are stated; where platforms change their limits often, check the current limit rather than trust a figure written months ago.

The launch page

Above the fold: the name, what it does in a sentence a stranger can repeat, one primary call to action, and one piece of proof you can defend. One action, repeated down the page, rather than signup competing with a demo request and a newsletter box. Signed off by the founder, who owns the positioning. It fails when the fold is checked only at desktop width, so on a real handset it holds a hero image, a cookie banner and nothing else.

Open Graph and card tags

Use 1200 by 630 pixels, the ratio the major platforms support consistently and which crops acceptably into a square preview, with any text inside the middle 80 per cent. File size ceilings move, so check the current limit before exporting. Tags needed: og:title, og:description, og:image, og:image:alt, og:url pointing at the canonical URL, og:type, and twitter:card set to summary_large_image with matching title, description and image.

Platforms cache preview data, so a broken image seen by the first sharer can persist for everyone who shares afterwards. Publish the tags days early, then use each platform's own debugging tool to force a refresh and confirm the render.

The demo video

Under two minutes for the main cut, with a 30 second version for feeds. The product should be visible doing something recognisable within five seconds; a logo animation spends the only attention you were given. Assume silent autoplay: burn captions into social cuts where you do not control the player, and supply a caption file for your own player. Export 16:9 for the site, plus vertical and square crops for the feeds you post in.

Product screenshots

Real data, never placeholder text. A frame containing lorem ipsum or a user called Test Test reads as a product nobody uses, so build a demo account with plausible names, values and history and keep it. Choose light or dark and hold it across the set. Capture at twice display resolution to survive retina screens and press cropping, export at the ratio each destination expects, and write alt text as you go.

The launch post

The announcement on your own site, in two versions. The long one runs roughly 600 to 900 words and covers what it is, who it is for, what it replaces, what it costs and what happens next. The short one runs under 100 words, because that is what people paste into messages.

Community and press copy

A paste-ready block a third party can use unedited: two sentences of description, one line on availability and price, the canonical URL, a contact address, and a link to a folder holding the logo, a screenshot and a founder photograph, in the third person. It is the asset most often skipped and most often used: a writer under deadline pastes what you gave them, and if you gave them nothing they write their own and that version spreads.

The email to your list

One email, one call to action, to people who already agreed to hear from you. Keep the subject line short enough to survive a phone inbox, since a handset shows far less than your desktop client. Include a plain text alternative, check rendering in the clients your audience uses, and confirm sending domain authentication before launch week.

The FAQ page

Six to twelve questions with answers that stand on their own, taken from sales calls: price, what happens after a trial, data handling, integrations, and the limitation your product genuinely has, stated plainly. Mark it up as an FAQ page with matching visible text. Rich result eligibility for that markup has been narrowed before and may narrow again, so build the page for readers and for the retrieval systems described in answer engine optimisation for product launches.

Support macros and a known-issues document

Ten to fifteen saved replies for predictable questions: pricing, refunds, the free tier boundary, the integration you do not support, account deletion. Alongside them, a document listing everything broken or half-built, with agreed wording and a named owner for each fix. Without it, three people answer the same question three ways in public on the day the most people are reading.

The pricing page

Actual numbers, currency, billing period, what happens at the end of a trial, and what happens when a limit is exceeded. It fails through a comparison table unreadable on a narrow screen, and through page numbers disagreeing with the billing system, which somebody should verify in live mode. The reasoning behind the numbers belongs in the guide to launch pricing.

The status page

Needed if your product can go down in a way customers notice, in which case it exists before launch, not mid-incident. Host it on infrastructure separate from the product, on a subdomain with its own DNS, so it stays up when the application does not, and pre-write an acknowledgement template and a resolution template.

The dry run, three days before

Three days out, one person walks the entire path on a real mid-range Android phone on mobile data. Not a simulator, not a flagship on office wifi: the point is to experience what most launch day visitors will.

• Start from a shared link pasted into a messaging app, so you see the preview card as a recipient does.
• Land on the page and note what is visible before scrolling, with the cookie banner and any in-app browser chrome in place.
• Play the video muted, confirming captions appear unasked.
• Complete signup, including email confirmation, on the phone.
• Pay in live mode with a real card, using a method common in your buyers' market rather than the one you use, then refund yourself.
• Reach first value and watch the activation event fire in analytics.
• Read the confirmation and welcome emails on the phone, checking links.

Log every hesitation, since hesitation on a rehearsed path by somebody who built the product predicts abandonment by somebody who did not. Fix what is fixable in three days and put the rest on the post-launch list. Running the launch readiness check the same day gives a second, less forgiving view.

What to freeze, and why nothing ships on launch day

From the end of the dry run until the day after launch, nothing ships except reverts. No copy edits, no pricing changes, no feature flags flipped on a whim. The reason is operational: you cannot debug a deploy and a launch at once, and one of them will need your full attention. When signups stall at two in the afternoon, the question is whether the cause is traffic, the payment provider or the change pushed at noon, and a freeze removes the third answer.

Keep a change log so deferred work stays visible, and ship the batch the morning after launch when there is capacity to watch it. Teams that honour that list enforce the freeze easily the second time; teams that let it expire unread find the next one negotiated away in the first meeting, one of the patterns behind the launch readiness framework.

The full asset list

Deadlines are relative to launch day, so L-3 means three days before, and assets with external dependencies sit earlier because that turnaround is not yours to control.

What to cut if you are short of time

Sometimes the date will not move and the list will not finish. Cut in this order, and price each cut, because a deliberate omission differs from one abandoned at midnight.

1. The social cut of the video. Cost: less reach in feeds, where the long cut performs poorly, though the page still has a video.
2. The long launch post. Cost: less material for people writing about you, and one fewer indexable page carrying your category words.
3. The status page, if and only if downtime would be invisible to customers. Cost: an incident becomes a burst of tickets asking one question on the day you have least capacity to answer individually.
4. Extra screenshot crops. Cost: badly cropped images on some surfaces, which reads as carelessness rather than the time constraint it was.
5. The FAQ page. Cost is higher than it looks, since you lose the objection handling and your most quotable format, so put it back the week after launch.

What does not get cut: the launch page, the Open Graph tags, the paste-ready block, the support macros and the dry run. Those five show their absence on the day itself, in traffic arriving to a broken preview, in a description written by somebody who guessed, and in support replies that contradict each other in front of the largest audience you will have all year.