Launch Day Timeline: A Call Sheet for the First Six Hours

Launch day is six hours of scheduled work followed by an open-ended watch. The first hour is setup and the mint, the next two decide whether anything has a rhythm, and the last three are where most desks either hold their discipline or stop posting. Running it as a call sheet, with named slots and named people, is the difference between a launch and an afternoon of refreshing.

This page is the running order for the launch day phase. It does not cover what you spend, which belongs to the budget for the curve, and it does not cover how to read a holder list. It covers time: who is on, what happens in each slot, which decisions have deadlines attached, and what to do when the running order slips, because it will.

SCHEDULED

Six hours in slots, from T-60 to T+300, then a lighter watch rota.

ROLES

Desk lead, comms, watcher. One person can hold two of them badly.

PRE-WRITTEN

Every scheduled post is drafted the day before. Nothing is composed live.

NOT YOURS

Who buys, when attention arrives, and whether the curve completes.

What launch day is, and what it is not

Launch day is an operations problem. Everything that can be decided in advance has been decided, the fields are frozen, the wallets are funded, and the remaining job is to execute a sequence while under mild pressure and in public. Treated that way it is manageable. Treated as the day your project either works or does not, it becomes six hours of reacting to a chart.

The distinction matters because it determines what you measure yourself against at the end. A desk that ran its slots, answered its questions and logged its day did its job, whatever the curve did. Nobody running a launch controls who buys, when attention arrives, or whether a curve completes. What you control is whether you were present, accurate and on time.

The schedule is also a defence against the two failure modes that show up on every quiet launch. The first is silence: the team stops posting because there is nothing good to report, which reads from outside as abandonment. The second is thrash: the team starts improvising, changing the message every twenty minutes, and the audience watches the panic. A call sheet prevents both by removing the question of what to do next.

Three roles, and the solo founder version

Three roles cover a launch day. The desk lead owns decisions and the clock. Comms owns everything published outward and everything answered inward. The watcher owns the screens: the curve, the explorer, the holder list, and any automation that is running. Roles are not seniority. They are attention, and the point of splitting them is that no one person can hold all three at once.

The desk lead does the least visible work and the most important. They keep the schedule, they call the decisions that have deadlines, they decide when to move to a lighter rota, and they are the only person who may change the plan. If the lead is also writing posts, the plan will change silently, because the person holding it is busy.

Comms writes nothing new on the day if the preparation was done. They post the pre-written material at the scheduled slot, answer questions in their own words, and escalate anything that requires a decision rather than answering it themselves. The most common comms failure is not rudeness, it is a well-meaning person inventing an answer about supply, team allocation or plans, live, under pressure.

The watcher keeps the monitoring surfaces open and reports rather than interprets: the launchpad page, a block explorer such as the Solana explorer, the holder view, and, where automation is part of the plan, the dashboard of whatever is running, for example a Solana volume bot. It is worth stating in the room what that last surface shows: recorded transactions, which are not demand, produced by a tool that does not control who turns up.

A solo founder holds all three roles and must therefore run a smaller day. The way to do that is not to work harder in the hour; it is to move work backwards into the days before. Fewer slots, every post already written, a fixed answer sheet for common questions, and an explicit acceptance that some messages will be answered in the next slot rather than immediately.

The right hand column is not a compromised version of the left. It is a different plan with a different shape, and a solo founder who tries to run the three-person sheet will miss slots for the first two hours and then abandon it. Choose the column before the day rather than discovering which one you are in at T plus ninety.

T-60 to T-0: the setup hour

The hour before the mint has no audience and therefore no excuse for improvisation. Everything in it is checking, and everything being checked was supposed to be finished yesterday. The purpose of the hour is to find the one thing that is not ready while it is still cheap to fix. It is also the last quiet hour anyone on the desk will get.

• Signing wallet funded, on the correct machine, with the person who holds it present.
• Approved metadata file open, so fields are pasted rather than typed.
• Every pre-written post loaded in a draft, in the channel it belongs to.
• Monitoring surfaces open in fixed tabs, in a fixed order, on the watcher's screen.
• The answer sheet for common questions open in front of comms.
• The log file created, with the first row already written.
• Time source agreed, so that T-0 means the same moment to everyone.

Agree one clock. Different devices, different time zones and different opinions about when the launch starts are how a desk ends up publishing the address before the mint has confirmed. Write the target T-0 in a single message, in a single time zone, and refer to every later slot as an offset from it rather than as a wall clock time.

Do not publish anything in this hour that implies a precise minute unless you are certain of it. Saying that a launch is happening within the hour is safe and true. Saying it happens at a named minute creates an audience that watches that minute pass, and a launch that opens two minutes late with people watching feels much worse than one that opens without a countdown.

The six-hour call sheet

The table below is the running order this desk uses as a default. Times are offsets from the mint. Adapt the intervals to your team size, but keep the structure: every slot has a person, an output, and a decision that is due. A slot with no decision attached is a slot people forget to attend.

Notice how little is published. Four to five outward posts across six hours is a deliberate rate. The temptation on a live day is to fill silence with commentary, and commentary about your own curve is the single fastest way to sound anxious. Presence is answering questions; publishing is a scheduled act with a written text behind it.

The mint moment and the first ten minutes

The mint itself is a transaction. It confirms in well under a second on Solana, and the emotional weight people attach to the moment is entirely on your side of the screen. Sign it, wait for confirmation, and copy the mint address into the log before you do anything else. That copy is the reference every later message and every later check is made against.

Then publish the address, in plain text, in every channel you own. Plain text matters because it survives being screenshotted, quoted and pasted, and because an address inside an image cannot be verified by the person reading it. This is also the moment where copies of your token can appear, and the only defence available is that the correct address is easy to find in the place people already trust.

Check the address you published against the log, in every channel, before the ten minute mark. A wrong character in one channel is a small typing error and a large real problem, and it is far easier to correct three minutes after posting than an hour later when it has been quoted. This is the check the T+3 slot exists for.

The first ten minutes will also produce your first direct messages, and some of them will be offers: promotion, listings, market making, urgent opportunities that expire in an hour. Treat every unsolicited approach on launch day as noise to be handled tomorrow. The desk has one job today and it is not evaluating counterparties while a curve is live.

Hour one, hours two and three, hours four to six

Hour one is about correctness rather than growth. Is the address right everywhere, does the page render, is the image loading, are the links working, is anyone able to trade. The watcher reports what the screens say without adjectives, and the desk lead is listening for anything broken rather than anything encouraging. At T+60 the team spends five spoken minutes on whether to continue as planned.

Hours two and three are where the day acquires its shape, and where the early buying pattern becomes readable. This is the window in which a holder list stops being three addresses and starts being a distribution, and reading it honestly is a skill of its own, covered in first buyers and distribution. The watcher's job here is to describe, not to reassure.

Hours two and three are also where a desk first feels the pull to change the plan. Somebody suggests a new channel, a different message, an unscheduled announcement. The rule is that the desk lead may change the plan and nobody else may, and that any change is written into the log with the time it was made. Improvisation is not banned; unrecorded improvisation is.

Hours four to six are the discipline hours. Attention has either arrived or it has not, and the desk is tired either way. The published rate slows and the answering rate does not. If the curve is quiet, this is the block where the honest diagnosis starts rather than the block where people quietly stop replying, and the sequence for that is set out in the stall triage.

Here is the arithmetic on publishing, purely as an illustration of why posts are written in advance. Suppose comms publishes every forty-five minutes across six hours: that is eight scheduled posts. If each one takes twelve minutes to write and check, the day contains ninety-six minutes of writing. There is no ninety-six minute gap on a launch day, which is why the drafts exist before T-60.

The decisions that have deadlines

Most launch day decisions are not hard, they are late. A decision made at T+45 that should have been made at T+30 is worse than either option would have been on time, because the desk spent fifteen minutes half-committed. Attach every decision to a slot, give it a default, and make the default what happens if nobody calls it.

Write the defaults down before the day in plain if-then form. If the address is wrong in a channel, correct it immediately and post a one line correction. If a question cannot be answered accurately, say it will be answered by the next slot and then answer it. If the desk lead is unreachable at a decision slot, the default holds and nothing new is spent or published.

Sizing is the decision teams most often leave open, and it should be closed before the day rather than argued live. How much activity a launch plans for is a number you set in advance from what you are willing to spend, not one you discover by watching a chart; there is no universal correct figure, and material such as how much volume a token needs is a framing exercise rather than an answer. Recorded activity is not demand, and nobody controls who turns up.

As an illustration of the shape rather than the size: if the desk decides in advance that ten SOL is the day's ceiling for any planned activity and splits it into two windows of five, then the T+120 slot has a real decision in front of it. Spend the second window, hold it, or stop. A ceiling written down beforehand turns that into a ten second answer instead of a forty minute argument.

The other deadline decision is the one nobody schedules: when to stop. Put it in the sheet at T+300. Ending the scheduled day at a written time, with an announced handover, is an act of competence. Ending it because people drifted off one by one leaves an audience watching a channel where the last message was three hours ago.

When a slot slips

Slots slip. The mint is late, a post is not ready, the person on comms is dealing with something real, the watcher missed a check because a tab was logged out. The failure is not the slip; it is the twenty minutes afterwards where the desk pretends the schedule is intact and everyone privately works from a different version of the plan.

1. Name it out loud, immediately: which slot, how late, and who noticed. No apology, no explanation yet.
2. Decide whether the slot moves or is dropped. Announcements move. Reviews and checks are dropped rather than stacked.
3. Rebuild the offsets from the new zero if the mint itself moved, and restate T+ times once, in one message.
4. If anything was published against the old timing, issue a one line correction in the same channel. Do not delete and repost.
5. Write the slip into the log with the time and the cause while it is fresh, in one sentence.
6. Confirm the next two slots explicitly with the people who own them, so the recovery does not slip as well.

Dropping a slot is usually better than stacking it. Two reviews held back to back produce one review and a lot of catching up, and a post published forty minutes late alongside the next one reads as a burst from a team that went quiet. If the moment for a piece of content has passed, the content has passed with it.

The one thing that never slips is a correction. If something published is wrong, the correction goes out in the slot it was found in, not the next one. Corrections are cheap on the day they happen and expensive on any day after, and a desk that corrects itself quickly buys credibility that no amount of scheduled content will.

The log, and the overnight handover

Keep a plain log. One file, one line per event, each line carrying a time, what happened and who recorded it. It takes seconds per entry and it is the only way to review the day afterwards without relying on memory that has already been reshaped by how the day felt. Screenshots are not a log; they are evidence without a timeline.

Log the mint address and confirmation, every publication with its slot, every question that needed escalating, every decision with the option chosen, every slip with its cause, and each watcher reading at the slots that call for one. Keep any automated activity as its own labelled line rather than mixing it into observations about the curve, so that the record separates what you did from what happened.

The review comes later, not tonight. A team reading its own log at midnight on launch day will argue about feelings; the same team reading it two days later will find three process problems and fix them. The log is written for that reader. It is also, in a real sense, the only durable output the desk produces on a day where everything else is outside your control.

The handover at T+300 is a short announcement and a named person. Say the scheduled day is closing, say who is watching, and say when the next update comes. The person on overnight watch is not on shift; they are on call, with a written trigger list of what wakes them, which should be short: something broken, something published incorrectly, or a question that cannot wait.

Everything in this timeline assumes the preparation was finished. If the metadata was still being argued about at T-30, or the wallet policy was unclear, or nobody had written the answer sheet, then the day was decided before it started and no schedule saves it. That work belongs to the pre-launch sign-off sheet, and it is the cheapest work in the whole launch.

Run the sheet, keep the log, correct fast, and end the day on a decision rather than on exhaustion. Whether attention arrives, who buys, and whether the curve completes are not yours to arrange. Whether the desk was where it said it would be, saying only things that were true, is entirely yours, and it is the part anyone watching will remember afterwards.

Questions the desk is asked