6. Go live

Production is the real thing, with real users and real data. It is deliberately harder to touch than staging.

First, check you are ready

I want to go to production. First review whether this project is actually ready and give me a plain GO or NO-GO with reasons. Do not deploy anything yet.

Fix whatever comes back. Only then:

Deploy to production and give me the URL.

Your assistant will ask you to confirm

That is intentional. It should ask every single time, even if you approved a production deploy an hour ago. If it ever deploys to production without asking, that is a bug — tell us.

Your own domain

Help me point yourdomain.com at this production deployment.

The project has to be told its own address — it is not guessed from the visit — so a new domain means one setting changed and one more deploy. If signing in stops working immediately after a domain change, this is why, every time:

The site is now at yourdomain.com. Update whatever still names the old address, then deploy again.

Done when

Your domain loads your app.

After you are live

Make the change in staging, look at it there, then deploy the same thing to production. That is the whole discipline, and it is what staging is for.

When something is wrong on the live site, run pnpm support in the project and hand the report to your assistant before changing anything — it names what is actually different about that environment, which is faster than guessing and safer than editing production to find out.