Skip to main content
Sign In

Write a production launch checklist for future you

Turn your wallet failure experiments into a DEV post that helps other developers write clearer, more useful transaction errors.
Write a production launch checklist for future you background
View Your Submissions
Challenge

Write a production launch checklist for future you

A checklist is what stands between “I think I deployed everything correctly” and “I know I did.” Pilots run one before every takeoff, surgeons run one before every incision, and not because they forgot how to fly or operate. They run it because the cost of skipping a single step under pressure is too high to trust memory. Shipping a Solana program to mainnet-beta is the same kind of moment: irreversible actions, real value at stake, and a dozen small things that each seem obvious right up until the one you forget.

Over the last five days you built every piece of a real launch. You promoted a program from devnet to mainnet-beta, took deliberate control of its upgrade authority, published an IDL and generated a typed client with Codama, wired a React frontend through the Wallet Standard, and taught that frontend to catch and classify errors before they reached anyone. Today you turn that lived experience into a document: a reusable launch checklist you can run every time you ship, and that someone else could follow without having to relearn what you already know.

The scenario

It is three weeks from now. You have a new program, smaller than the one you just shipped, and you are about to put it on mainnet-beta. You open your terminal, and then you pause. What was the order again? Did you confirm the upgrade authority before or after the deploy? Did the IDL need to be published separately? Was there a flag you forgot last time that cost you a failed transaction and a recovered buffer account?

This is exactly the gap a checklist closes. The knowledge is in your head today because you just did it. In three weeks it will have faded, and “I’ll remember” is not a launch strategy. A good launch checklist is the gift your present self gives your future self, and publishing it means it becomes a gift to every other developer making their first mainnet deploy too. That is what a Document day is for: taking something you understand and making it durable and shareable.

The challenge

Write a launch checklist as a blog post and publish it. The checklist should walk through a Solana program launch in the order the steps actually happen, grouped into clear phases, with each item written so that someone could follow it without already knowing the answer. You are not inventing new procedure here. You are documenting the path you walked across Days 85 through 89, in your own words, with the gotchas you personally hit called out.

What you’ll need

Steps

Structure your checklist around the four phases below. For each phase, write the items as checkable lines and add a one-sentence “why” for any step where the reason is not obvious. The phases and the items inside them are your scaffold; fill them in with the specifics from your own launch.

  1. Pre-flight, on devnet. These are the steps that catch problems while they are still cheap to fix. Document items like: every test passes against your final program build; you have run the program end-to-end on devnet exactly as it will run on mainnet; you produced a verifiable build with anchor build --verifiable so the on-chain bytecode can later be matched to your source; and your deploy wallet holds enough SOL to cover the rent-exempt minimum for the program account plus fees. Note the gotcha you learned: once you have a verifiable build, do not overwrite it with a plain anchor build or cargo build-sbf, because those can produce a different hash and break verification later.
  2. The deploy itself. This is the irreversible phase, so the checklist matters most here. Document switching your CLI to the mainnet-beta cluster and confirming it with solana config get before you run anything; the exact deploy command you used; and, if your last deploy struggled to land, the option to attach a priority fee. A priority fee is a small extra payment per unit of compute that nudges the current block leader to include your transaction ahead of others competing for the same block. You can add one to a deploy with --with-compute-unit-price, and route through a reliable RPC with --use-rpc. Call out the recovery note you want your future self to have: a deploy is not atomic, so if it is interrupted you may be left with a buffer account holding your SOL that you can resume from or close. The deployment docs describe this recovery flow.
  3. Authority and verification, right after deploy. Document confirming the program is live and inspecting it with solana program show <PROGRAM_ID> to read back its upgrade authority and confirm it is what you intended. Include the decision you made on Day 86 about who holds that authority: a single keypair you control, a Squads multisig where upgrades require multiple approvals, or --final to make the program permanently immutable. Each is a legitimate choice with different tradeoffs, so write down which you chose and why. Then document publishing your IDL and regenerating your Codama client, with the reminder that skipping the IDL publish will cause build verification to fail.
  4. Frontend and going live. Document pointing your React frontend at the mainnet program ID and confirming the Wallet Standard connection surfaces real wallets against mainnet. Include the error-handling pass from Day 89: confirm every failure mode you classified (rejected approval, insufficient funds, expired blockhash) still produces a calm, legible message now that the stakes are real. Finish with the human steps that are easy to forget: announce the launch, and write down where users should report problems.

Once the four phases are drafted, write a short intro that frames why you keep a checklist at all, and a short closing on the one thing that surprised you most across the launch. That personal note is what turns a generic list into something other developers actually want to read.

Run it

Before you publish, run the one command that confirms the most important fact in your whole checklist: that your program is live and its upgrade authority is exactly what you claim it is. Paste the output into your post as proof.

solana program show <YOUR_PROGRAM_ID> --url mainnet-beta

What just happened

You converted a one-time experience into a repeatable process. The first time you did each of these steps, you were learning them; the value lived only in your memory and would fade. By writing the checklist down in the order the steps happen, with the reasons attached, you made that knowledge survive past the moment, and you made it transferable to anyone else who reads it.

There is a deeper habit forming here too. The best engineering teams treat launches as procedures, not as feats of memory or heroics. A multisig on the upgrade authority, a verifiable build, a confirmed cluster before an irreversible command: these are not paranoia, they are the small disciplines that let teams ship to production calmly and repeatedly. You now have your own version of that discipline written down, which is a meaningful step toward shipping like a professional rather than improvising each time.

And by publishing it, you have done something the Solana ecosystem genuinely needs. The path from a first devnet deploy to a confident mainnet launch is exactly where many developers get stuck. Your checklist, written from the perspective of someone who just walked it, is more useful to a beginner than the reference docs precisely because you remember what was confusing.

Resources

Submission

Publish your launch checklist as a post on DEV and submit the link with the below.

Submit your project