The launch checklist should not live in my head

Near the end of a client project, the build is not usually the only thing left.

There is a second pile of work: access, accounts, decisions, content approvals, legal pages, walkthroughs, and a clear line between what blocks launch and what can wait. For PrintFetti, that pile became real the moment the owner asked for a complete list of what he still needed to provide. He was not wrong to ask. I had been carrying pieces of the answer across notes, assumptions, and unfinished follow-ups.

Writing the reply took longer than it should have. Not because the items were mysterious, but because I had to reconstruct a standard process from memory instead of sending a living checklist that already knew the project stage.

That is the product opportunity.

Clients should not have to invent the launch path

A good late-stage client message does three things at once:

• Invites real review of the product, not just a polite “looks good”
• Lists exactly what the client still owns
• Separates launch blockers from later improvements

For PrintFetti, the review side was straightforward: walk the customer order flow, walk the admin side, and send notes or join a short call. The harder part was the ownership list. Once I wrote it out, it looked obvious.

The checklist that always shows up

Every production launch needs a version of the same categories.

Access and accounts

These should usually end up client-owned, with me invited for configuration:

• DNS access for the live domain
• A transactional email account such as SendGrid
• Private object storage for uploads
• The production server or hosting account
• Optional analytics access if tracking is part of launch

The clean end state is simple: the client owns the infrastructure relationship. I help set it up cleanly. That keeps handoff sane later.

There is also a faster onboarding path when the client is busy or blocked: Always Coded Fresh can pay for and provision the server, email, and storage first, get the app live, and transfer ownership when the client is ready. That should still be an explicit checklist choice, not an invisible exception.

Decisions and addresses

Launch is blocked by small decisions people forget until the last day:

• Exact production domain and preferred www behavior
• The public “From” email customers will see
• The inbox that receives order and contact notifications
• Staff emails that need administrator accounts
• Payment process for the MVP, including what is intentionally not integrated yet
• Written approval that staging is ready to go live

Content and legal

These are not “nice to have” if the site is public:

• Final product categories and starting prices
• Real photos, or written approval to launch with current mockups
• Real testimonials, or approval to remove sample ones
• Terms, privacy, shipping, returns, and reprint language
• Final logo and favicon files if anything changed

Explicitly not required for launch

This section matters as much as the required list. If everything feels urgent, nothing is.

For PrintFetti, polish on the customer portal, dynamic pricing admin, Stripe, QuickBooks API work, and long-term GitHub ownership for the client team can wait until after go-live. Naming those items reduces anxiety and protects the schedule.

Walkthroughs are part of the checklist

A checklist without proof is just more text.

The client should be able to review the product as a customer and as an admin without me narrating every click live. A short walkthrough video, a staging link, and a place to leave notes would cover most of that. A live call is still useful, but it should not be the only way the client can understand the system.

That is also why this belongs in a client portal, not only in email:

• Checklist items with owners and due dates
• Status for each access grant and decision
• Uploaded assets linked to the item they satisfy
• Embedded or linked walkthroughs for key flows
• A launch gate that cannot flip green until blockers are cleared

Email can still notify people. The portal should hold the source of truth.

Onboarding and production should feel like 1-2-3

The launch checklist is only half of the process. Getting a client onto production infrastructure should be just as simple.

Client onboarding path:

• Pick ownership model — client creates accounts and invites me, or I provision under Always Coded Fresh and transfer later
• Complete the portal checklist — domain, DNS, email, storage, admins, content, legal, and approvals
• Approve cutover after staging review — walkthroughs done, blockers cleared, go-live scheduled

Production and deployment path:

• Provision the environment — server or containers, DNS, SSL, env vars, storage, email
• Deploy with one known command or pipeline — dependencies, assets, migrations, restart
• Verify and hand off — health checks, smoke tests, backups, monitoring, short runbook

Docker can be part of that path. So can plain Linux, systemd, PaaS, or a hybrid. The packaging choice matters less than whether a stranger with access can follow the same three steps without improvising.

If paying for the droplet, Spaces, or SendGrid for a week makes onboarding easier, that should be an intentional service option with transfer steps already written. The process exists to remove friction, not to force the client through every vendor signup before they have seen value.

Client files and email need the same discipline

The launch checklist fails if the supporting organization is a mess. Every client should get the same automated folder structure for contracts, discovery, brand, content, credentials indexes, runbooks, deliverables, and archive.

The first automation step there is email sync. Approvals, access details, and “final” files often live in threads first. Those messages and attachments should flow into the client’s project directory and portal record instead of depending on me remembering to file them later.

Then protect the archive. Client data should not exist only inside one paid drive, mailbox, or SaaS account. Keep an independent cloud backup and a physical or offline encrypted copy of the records that would hurt to lose: contracts, legal approvals, production handoff packages, and credential indexes. Working tools can be convenient. Recovery cannot depend on one subscription remaining friendly.

What I want to automate next

This is not a request for a giant autonomous agency overnight. It is a concrete automation candidate sitting right on top of a real delay.

First version:

• A reusable launch checklist template by project type
• Auto-filled items based on the stack already chosen for the project
• Client-facing walkthroughs generated from the features that are actually ready
• A status email drafted from checklist state instead of reconstructed from memory
• Clear labels for “blocks launch” versus “post-launch”
• A 1-2-3 production setup and deploy playbook that works with Docker or without it
• An onboarding option where the agency provisions infrastructure first and transfers ownership later
• A standard client organization directory tree created for every project
• Email sync into that structure as the first organization automation
• Backup rules that copy critical client data to independent cloud storage and physical/offline media, not only the primary paid tool

Later versions can go further: guided DNS setup, invite links for SendGrid or object storage, one-click or one-command environment provisioning, legal page drafts from a standard template, and reminders when a client item sits unanswered for too long.

The point is the same one I keep returning to with the broader agency process. The first useful systems are not the flashy ones. They are the repeated coordination and production tasks that eat an evening every time a project gets close to real.

Why this matters commercially

When a client asks, “What do you need from me?”, that is a good sign. It means they want to clear blockers.

If my answer is slow, incomplete, or scattered across threads, I become the bottleneck even when the code is ready. If my answer is a clean checklist with walkthroughs, ownership, and a post-launch bucket, the project feels managed.

PrintFetti made that obvious. The owner anticipated the list. I still had to assemble it by hand. Next time, the process should already be waiting.