Launch Mistakes That Repeat, Phase by Phase

Launch mistakes repeat because prevention is cheap and invisible while failure is expensive and public. Almost every error below was avoidable with a decision made calmly a week earlier, and almost every one of them was skipped because it produced nothing visible at the time. Grouping them by the phase that produced them is the fastest way to see which cheap step was missed.

This desk is independent and has no relationship with any launchpad. What follows is a description of failure patterns, not an accusation about any particular project, and it deliberately contains no invented statistics about how often each occurs. The useful content of a mistake list is the mechanism and the preventive step, not a percentage nobody measured.

Why the same mistakes come back

A launch compresses months of decisions into a few days, which means most decisions get made by whoever is awake rather than whoever should make them. Under compression, teams default to whatever they did last time. If last time was undocumented, the default is a rough memory of the good parts. That is the machinery by which an error survives into the next project.

The second mechanism is that preventive work has no visible output. Nobody congratulates a team for the broken link that was never live or the reserve that was never needed. The reward for prevention is an absence, and absences are hard to defend in a meeting when someone wants the hour spent on something with a screenshot attached.

Phase one: mistakes made before the mint

Launching without deciding what done means

Ask three people on a launch team separately what a successful outcome looks like and you will often get three answers, one of which is a price. This is the parent mistake. Without an agreed endpoint the team cannot distinguish a slow hour from a failed launch, so every decision during the launch becomes an argument about whether there is a problem at all.

The preventive step is one paragraph agreed before anything else, describing what the team intends to have built and what would count as having finished. It should be specific enough to be falsifiable and it should not contain a price, because price is not something the team controls. Sign it off and keep it where everyone can reread it in hour four.

A name or ticker nobody can find

A ticker that collides with an existing token, or a name that returns an unrelated result on any ordinary search, does permanent damage to the only free channel you have. Every mention someone makes routes attention somewhere else. The check costs a few minutes in a clean browser session, and the whole cost of skipping it lands after the field is fixed and unchangeable.

Broken links and the fields you misread

Missing or broken social links are the most common visible failure and among the least excusable. Teams check them while logged in, which hides redirects, dead handles and privacy settings a stranger will hit immediately. Walking every destination from a logged-out browser takes a quarter of an hour, and it is the last chance you get before the links appear next to a live token.

The mirror-image error is misunderstanding which fields are permanent. Some parts of a token setup cannot be revised once created and some can be updated at any time, and teams routinely agonise over the changeable ones while glancing at the fixed ones. Mark each field as fixed or editable on the sheet, as covered in the pre-launch sign-off sheet, and argue in proportion.

Phase two: mistakes made on launch day

Announcing before the token is live

The announcement goes out, the address is wrong or missing, and the first thing a stranger encounters is confusion. Worse, an impersonator now has a window in which people are actively looking for an address and will accept the first one offered. The rule is simple and absolute: nothing is published until one named person has opened the live page and read the address back.

Nobody awake in hour four

Rotas get written around the hours people want, which are the launch hour and the hours immediately after it. Hour four is when the initial wave has passed, questions accumulate, and a single unanswered message sets the tone for the rest of the day. Assign a name to every hour in the covered window, including the ones nobody volunteered for, before the day begins.

This is a scheduling problem with a scheduling fix, and it is the reason the desk publishes an hour-by-hour call sheet rather than a list of principles. A rota with a gap is not a rota. If the team is too small to cover a window honestly, shorten the window and say when the desk is staffed rather than pretending to a coverage you do not have.

Deleting the message instead of answering it

A hostile or awkward question arrives and a moderator removes it. Within minutes the deletion is the story, because someone screenshotted it and because deletion reads as confirmation. Agreeing in advance that questions receive answers, including the answer that you do not know yet, removes the whole category. Moderation should remove abuse and spam, not inconvenience.

Phase three: mistakes made on the curve

Silence when things go quiet

The instinct when activity falls is to say nothing until there is something good to report. Readers experience that as a team that vanished exactly when it got difficult, and it is close to irrecoverable. A short factual update at the same time every day, including the days where the update is that nothing moved, costs nothing and is the only thing consistency can be built from.

Spending before diagnosing

A quiet curve has several possible causes and they do not respond to the same treatment. A discovery problem, a distribution problem, a metadata problem and simple absence of interest look similar from the inside and need different responses, most of which are not money. Spending first is common because it feels like action, which is precisely why it should require a diagnosis, as the triage sequence for a quiet curve sets out.

Presenting manufactured activity as organic demand

This is the mistake that is also a misrepresentation, and it belongs in an operational list because it is usually decided operationally, late at night, by tired people who have run out of other ideas. Buying transactions produces transactions. It does not produce interest, and the resulting chart is a description of what you spent rather than of what anyone wanted.

The reason it fails as a tactic and not only as ethics is that the evidence is permanent and public. Swap records carry signers, sizes, intervals and counterparties, and repetition is visible to anyone who exports the list from a public Solana explorer. A team betting that nobody checks is betting against a database that stays open indefinitely.

Phase four: mistakes made after graduation

Assuming graduation

Plans are written for the outcome the team wants, so they describe the migration in detail and the alternative not at all. Curve thresholds and the conditions attached to them are set by the platform, can change, and must be read on the platform itself rather than taken from a secondhand summary. Check them at the launchpad you are using before writing any figure down.

Most launches do not complete their curve. A plan with no instructions for that case leaves the team improvising in the situation it was most likely to face, which is how the next three mistakes on this list get made. Write the non-completion plan first and the migration plan second, in that order, because the order reveals which one you actually thought about.

Abandoning the token the day after

Stopping work on a launch is a legitimate decision. Doing it without saying so is not, and it is the ending most launches actually have. The daily update becomes weekly, then stops, and holders assemble the conclusion from silence. Set a decision date in advance, hold it, and publish whichever outcome you reached in the same channel as everything else.

Blaming the market for a distribution problem

When price falls the ready explanation is conditions. Sometimes that is true. Often the holder list shows a concentration that made the fall arithmetic rather than sentiment, and nobody on the team had opened it that week. Read the distribution before writing the explanation, because the explanation you publish without looking is the one that gets checked first.

Recording nothing

The final mistake produces all the others next time. A launch generates decisions, spending, surprises and unanswered questions, and almost none of it survives in usable form unless someone writes it down while it happens. A running log kept from day one, closed with a post-mortem, is what converts an expensive week into something the next project can use. The template is at the end of this page.

The tooling decision taken at the wrong moment

Tooling failures are rarely about the tool. They are about when the decision was made. A console evaluated calmly in preparation gets judged on custody, cost and what it reports. The same console evaluated in hour three of a quiet launch gets judged on whether it might make the chart move, which is not a question any honest evaluation answers.

If external tooling is going to be considered at all, evaluate it during preparation on three axes. Custody: does it require your keys, and what happens to funds if the provider stops operating. Pricing: is the charge fixed, proportional, or open-ended, and who bears failed transaction costs. Reporting: are the figures it shows measured from chain data or estimated by the product itself.

Those questions apply to any product in the category, including Solana Volume Bot Pro, which like its competitors submits trades against pool venues on a schedule and reports on what it submitted. The evaluation point is that such a product records activity it was paid to create. That is not demand, and describing it to holders as organic interest is a misrepresentation rather than a marketing choice.

What prevention costs against what it avoids

The argument for preventive work is easier to make with arithmetic than with principle. The figures below are illustrative, chosen for clean division, and are not measurements of any real launch. They assume a launch budget of 40 SOL with a fifth of it, 8 SOL, ring-fenced as an untouched reserve, which is a structure rather than a recommendation about size.

As an illustration, take the logged-out link sweep. Walking six destinations takes roughly fifteen minutes and costs nothing. Now suppose it is skipped and a broken link is discovered in hour two, after the announcement has circulated. The correction consumes the entire 8 SOL reserve on re-announcement, which is a fifth of the budget, and hour six now has nothing behind it.

The same shape recurs across the list. Confirming the token is live before publishing costs one minute and prevents a correction that has to be issued into an audience already reading the wrong address. Naming an owner for hour four costs one line in a rota. Writing the non-completion plan costs a single meeting and prevents the entire fourth phase being improvised.

The pattern in that table is the argument. Every preventive step is measured in minutes and every avoided cost is measured in either budget or credibility. The asymmetry is not marginal, and it is stable across launches of very different sizes, because the preventive work does not scale with the budget while the damage does.

The preventive checklist

The list below is a condensed pass over the whole page, ordered so that everything on it can be completed before the mint transaction is signed. It is not a substitute for a full sign-off sheet, which is grouped by owner and covers considerably more ground. It is the subset that specifically prevents the failures described above.

• One paragraph, agreed and written, defining what finishing looks like, containing no price.
• Every name and ticker candidate searched from a clean browser before the field is fixed.
• Each setup field marked as permanent or editable, with the permanent ones reviewed twice.
• Every link you control opened from a logged-out session and confirmed to resolve.
• A budget with a ring-fenced reserve nobody may allocate in advance.
• External tooling evaluated on custody, pricing and reporting, and approved or rejected in writing.
• A written rule that manufactured activity will not be presented as organic demand.
• A rota with a named person against every hour in the covered window.
• A moderation rule that questions receive answers rather than deletion.
• A fixed daily publishing time that holds regardless of the numbers.
• A triage sequence to run before any spending decision on a quiet curve.
• A written plan for the curve not completing, drafted before the migration plan.
• A decision date after which the team publishes continue, reduce or stop.
• A running log started on day one, with one person responsible for it.

A post-mortem in one page

The post-mortem exists so the next launch does not restart this list from the beginning. One page is the target, and brevity is a feature. A thorough document nobody writes is worth less than a rough one that exists, so the template below is deliberately short enough to be completed in a single sitting within a few days of the launch ending.

1. State the date range the launch covered and who was on the team, by role rather than by name.
2. Write the definition of finishing you agreed in preparation, copied without editing it afterwards.
3. Build a plain timeline of what actually happened, hour by hour for day one and day by day after.
4. List the decisions taken during the launch, who took each, and whether it was planned or improvised.
5. Record what was budgeted against what was spent, including anything the reserve was used for.
6. List every question you could not answer at the time, and whether it has since been answered.
7. Note each moment the team departed from the plan, and what the plan had assumed instead.
8. Read the holder distribution as it finally stood and record it without interpretation.
9. Name the three things that would have made the largest difference if done a week earlier.
10. Write the changes for the next launch as instructions, not as observations.
11. File the page somewhere the next project will actually open, and tell whoever will run it.

Step ten is where most post-mortems fail. Observations sound like conclusions but instruct nobody, and the difference between saying that communication was inconsistent and saying that updates go out at a fixed hour with a named owner is the difference between a document and a change. Write every line as something a person can do.

None of this makes a launch work. A team can prevent every mistake on this page and still find that nobody was interested, because interest is not something the operating side controls and no plan or product can supply it. What the list controls is the category of failure that was self-inflicted, which is a smaller ambition and the only honest one available.

That distinction is worth keeping in front of the team throughout, and it is the organising idea behind everything in the preparation section. Do the controllable work properly, describe the rest accurately, and accept that the outcome will be decided by people whose behaviour you can neither predict nor direct. Launches that end badly usually failed at the first of those, not the third.

Questions the desk is asked