Day 6 presentation1 / 16

Zero to MVP AI Bootcamp

Deploy, demo & launch

Package the completed product, deploy it securely, practice recovery, and tell a clear launch story.

Today you ship

The complete AI Lead Assistant live over HTTPS with a rehearsed demo and public launch.

Scroll to move through the presentation.

Learning objectives2 / 16

By the end of today

  1. 1Explain a server, container, domain, and HTTPS in product terms.
  2. 2Deploy the instructor-tested application package to Google Cloud.
  3. 3Verify runtime secrets, health, HTTPS, and the complete lead journey.
  4. 4Restore a known-good version after a controlled failure.
  5. 5Deliver a two-minute demo and publish one clear launch invitation.
Run of show3 / 16

Today’s learning path

  1. Module 140 min

    From project to running product

  2. Module 245 min

    Secure deployment and recovery

  3. Module 335 min

    The launch proof

  4. Module 440 min

    The two-minute story

  5. Guided build

    AI Lead Assistant · Final release

    Build, test, checkpoint, and ship.

Module 1 · Learn · 40 min4 / 16

From project to running product

Deployment moves the working application from your laptop into a repeatable package that Google Cloud can run at a public address.

A real example

Docker packages the app and runtime. Cloud Run starts that package, provides HTTPS, and creates a revision whenever a new version is deployed.

Technical terms

Container
A repeatable package containing the application and what it needs to run.
Revision
One deployed version of the Cloud Run service.
Module 1 · Apply it5 / 16

Apply the concept

Label the path from browser to HTTPS, cloud service, application, database, and AI provider.

  1. 1Run the complete product locally from the final checkpoint.
  2. 2Build the container using the instructor-tested configuration.
  3. 3Provide private runtime variables through the cloud service.
  4. 4Deploy and confirm the service health and public HTTPS address.

Use this prompt

Inspect this project's deployment files. Explain what enters the Docker image, what remains a runtime secret, how the server starts, and what I should verify before deploying to Cloud Run. Do not change files.

Success looks like

The deployed revision becomes healthy and the public address loads without exposing build files or secrets.

Watch for

  • If the container works locally but not in Cloud Run, inspect startup logs and the required port.
  • If the build fails, read the first real error rather than the final summary line.
Module 2 · Learn · 45 min6 / 16

Secure deployment and recovery

A safe release has two plans: how to send traffic to the new version and how to restore the last working version if something goes wrong.

A real example

Revision 5 contains the new launch build. If the lead form fails, traffic is returned to healthy Revision 4 while the issue is investigated.

Technical terms

HTTPS
Encrypted communication between a visitor's browser and the product.
Rollback
Restoring traffic to a previously working version.
Module 2 · Apply it7 / 16

Apply the concept

Deploy, route traffic, trigger one controlled failure, and restore the known-good revision.

  1. 1Identify the current healthy revision before deployment.
  2. 2Deploy the new revision and verify health before announcing it.
  3. 3Trigger the instructor-approved controlled failure.
  4. 4Restore traffic to the healthy revision and rerun the core journey.

Use this prompt

Create a release checklist for this Cloud Run service: current revision, new deployment, health check, core-journey smoke test, rollback command, and post-rollback verification. Leave placeholders for service, project, and region.

Success looks like

You can identify the live revision, restore the previous version, and prove the product works afterward.

Watch for

  • Never delete the known-good revision before the launch is verified.
  • If rollback succeeds but users still see failure, verify traffic allocation and browser caching.
Module 3 · Learn · 35 min8 / 16

The launch proof

The launch checklist turns every promise into visible evidence. You test the same public journey a real visitor and business owner will use.

A real example

Evidence includes the public form, structured AI result, saved private lead, automation execution, test payment, alert, HTTPS, and successful rollback.

Technical terms

Smoke test
A short test of the most important journey after a release.
Evidence
A visible result that another person can verify.
Module 3 · Apply it9 / 16

Apply the concept

Run the final launch checklist with a partner and capture evidence for every gate.

  1. 1Reset the demo accounts and prepare realistic lead data.
  2. 2Run the visitor journey on the public HTTPS address.
  3. 3Verify private dashboard, workflow, test payment, and alerts.
  4. 4Capture proof and assign every failure before presenting.

Use this prompt

Turn these product promises into a launch checklist with action, expected result, evidence to capture, and pass/fail status. Order the checks by the real visitor journey.

Success looks like

Every launch promise has current evidence, and no unresolved failure blocks the two-minute demo.

Watch for

  • Do not mark a check passed because it worked yesterday; test the deployed revision.
  • If a nonessential feature fails, remove it from the demo rather than risking the core journey.
Module 4 · Learn · 40 min10 / 16

The two-minute story

A strong demo tells a customer story rather than listing technologies. Show the problem, complete journey, reason to trust the result, and one invitation.

A real example

Meet a consultant losing leads. Watch one visitor receive the right recommendation and the consultant receive a private follow-up. Then invite the audience to try it.

Technical terms

Demo
A short, prepared demonstration of the product's value.
Call to action
The one next step you ask the audience to take.
Module 4 · Apply it11 / 16

Apply the concept

Deliver the demo once, remove every unnecessary sentence, then present it again.

  1. 1Introduce the customer and problem in twenty seconds.
  2. 2Show the complete live journey in seventy seconds.
  3. 3Show privacy, quality, or reliability evidence in twenty seconds.
  4. 4Close with the outcome and one next action in ten seconds.

Use this prompt

Edit this product demo script to fit two minutes. Keep the customer problem, live journey, one trust proof, outcome, and one call to action. Remove technology lists and repeated claims.

Success looks like

A first-time viewer understands who the product helps, sees it work, trusts the proof, and knows what to do next.

Watch for

  • If the demo runs long, remove explanation before removing the visible product journey.
  • If a live step is unreliable, prepare a tested backup recording and state clearly when it is used.
Guided project12 / 16

Build brief

AI Lead Assistant · Final release

Deploy the same product built since Day 1, prove its complete journey, and launch it publicly.

User story

As a potential customer or business owner, I can use and trust the complete product at a secure public address.

Guided build · Part 113 / 16

Build it step by step

1

Freeze the checkpoint

Close launch blockers, remove unfinished controls, and save the final local version.

2

Build the container

Package the instructor-tested application and provide runtime configuration securely.

3

Deploy to Google Cloud

Create the new revision, verify health, and route public traffic to it.

Guided build · Part 214 / 16

Build it step by step

4

Verify HTTPS and journey

Run visitor, AI, login, privacy, workflow, payment, and alert checks on the public URL.

5

Prove recovery

Create a controlled failure and restore the last known-good revision.

6

Demo and launch

Present the two-minute story and publish the product link with one clear invitation.

Ship checkpoint15 / 16

Do not ship until

  • The public HTTPS product passes the complete lead journey.
  • Runtime secrets are absent from the image, browser, repository, and logs.
  • Privacy, AI quality, automation, test payment, and alert evidence are ready.
  • The rollback drill restores the known-good product.
  • The live demo fits within two minutes and the launch invitation is public.
Wrap and prepare16 / 16

Ship it. Show it. Prepare the next move.

After launch

  • Send personal follow-ups to the first five people who engage.
  • Schedule the first user interview and weekly product review.
  • Choose the first improvement based on observed user behavior, not a new feature wish list.
All presentationsBack to the bootcamp