Understanding Deployment: What Happens After You Click "Launch"

TL;DR: When you click 'launch' on an AI app builder, six things happen behind the scenes: your code is built into static and server-side artifacts, those artifacts are pushed to a CDN and serverless infrastructure, your domain's DNS is pointed at that infrastructure, SSL certificates are issued, your database is provisioned and seeded, and environment variables (API keys, secrets) are loaded. After that, monitoring and logs start collecting data. Understanding this layer matters because deployment is where most non-developer founders hit problems they can't debug --- DNS propagation, environment variable mismatches, build failures. This guide explains each phase in plain language, what each platform does differently, and the post-launch operational basics that separate working products from broken ones.

Introduction

For non-developer founders shipping with AI app builders, 'click launch' feels magical --- and most of the time, it works. But when it doesn't, the problems live in a layer most founders never learned about. DNS propagation. SSL certificate issuance. Build pipelines. Environment variables. CDN cache invalidation. The vocabulary alone is intimidating, and the AI builder doesn't always explain what's failing.

This guide demystifies deployment in plain language. What actually happens when you click launch, what each component does, what each platform handles differently, and what post-launch operational basics keep your app working. By the end, you'll understand the deployment layer well enough to debug the common problems and to ask the right questions when things break.

The 30-second version

When you click launch, the platform does six things.

1. Builds your code --- Turns your source code into the files that actually run (HTML, JS bundles, server functions)
2. Pushes to infrastructure --- Sends those files to servers around the world (CDN for static, serverless functions for dynamic)
3. Configures DNS --- Points your domain (yourbrand.com) at that infrastructure
4. Issues SSL --- Gets the green padlock so the URL is https:// not http://
5. Provisions database --- Creates the production database and seeds it with the schema
6. Loads environment variables --- Connects to Stripe, OpenAI, Resend, and other services using API keys

Each of these can fail independently. Understanding which one is failing is how you debug deployment problems.

Phase 1: The build

Your source code isn't what runs in production. The build phase converts source into runnable artifacts.

What happens during build

• JavaScript/TypeScript transpilation --- Modern code (TypeScript, JSX, ES2024) compiles down to older JavaScript that all browsers can run
• Bundling --- Hundreds of source files get combined into a few optimized bundles for faster loading
• Minification --- Code gets compressed (variable names shortened, whitespace removed) to reduce file size
• Tree shaking --- Unused code gets eliminated from bundles
• Static page generation --- Pages that don't need user-specific data can be pre-rendered as HTML
• Asset optimization --- Images get compressed; CSS gets purged of unused styles

Why builds fail

• Missing dependency --- Your code references a package that wasn't installed
• TypeScript error --- Type mismatches that the build catches even though preview ran fine
• Out-of-memory --- Large projects exceed the build server's memory limit
• Missing environment variable referenced at build time --- Some env vars need to exist during build, not just runtime
• Version mismatch --- Node.js or npm version differs between preview and build

When a build fails, the AI app builder typically surfaces the error logs. Reading those logs is the first debugging skill. The errors are often more legible than they look --- 'Cannot find module X' usually means X is referenced but not installed; 'Type Y is not assignable' means a type mismatch in TypeScript.

Phase 2: Pushing to infrastructure

Modern web apps run on two types of infrastructure, often together.

Static files on a CDN

Your HTML, CSS, JavaScript bundles, and images go to a CDN (Content Delivery Network). A CDN has servers around the world --- Cloudflare has 300+ locations, AWS CloudFront has 600+ --- and the closest server to each user serves the files. This is why your app loads in milliseconds whether the user is in São Paulo or Singapore.

Server-side code on serverless or edge functions

Code that needs to run on demand (API endpoints, database queries, AI calls) gets deployed as serverless functions. These spin up when a user makes a request, run for a few hundred milliseconds, then disappear. You pay only for execution time, not for idle servers. Edge functions are a subset that run at the CDN's edge locations for ultra-low latency.

Database hosting

Databases need persistent storage and aren't a good fit for serverless. They typically live on dedicated managed database services --- Supabase Postgres, Neon, PlanetScale, MongoDB Atlas, AWS RDS. Your AI app builder either provisions one automatically or connects to one you specify.

Phase 3: DNS --- pointing your domain at the right place

DNS (Domain Name System) is how 'yourbrand.com' becomes 'the actual server serving your app.' The DNS configuration tells the internet where to find your app.

The records that matter

• A record --- Points your root domain (yourbrand.com) to an IP address
• CNAME record --- Points a subdomain (app.yourbrand.com) to another domain (cname.vercel-dns.com)
• MX record --- Tells the internet which servers handle email for your domain
• TXT record --- Stores arbitrary text, used for SPF/DKIM/DMARC email authentication and domain verification

DNS propagation: the most common gotcha

When you change DNS records, the change takes time to spread across the internet --- anywhere from 5 minutes to 48 hours, depending on cache settings. During propagation, some users see the old version (or no version) while others see the new version. This is normal and not a sign that something is broken.

Tools like whatsmydns.net let you check propagation across global DNS servers. If your change isn't propagating after 24 hours, there's usually a TTL (time-to-live) issue or a record mismatch. The AI app builder typically gives you the exact records to add; copying them exactly avoids most issues.

Phase 4: SSL --- getting the green padlock

Modern browsers warn users about non-HTTPS sites. SSL certificates (technically TLS certificates) make your site load over https:// instead of http://. Without SSL, browsers display warnings, search engines penalize ranking, and customers don't trust you.

Automatic SSL via Let's Encrypt

Every major AI app builder issues SSL certificates automatically via Let's Encrypt --- a free, automated certificate authority. The process: the platform proves to Let's Encrypt that you control the domain (via DNS or HTTP verification), Let's Encrypt issues a certificate, the platform installs it. Certificates auto-renew every 90 days. You don't have to think about this most of the time.

When SSL fails

• DNS not propagated yet --- SSL issuance needs the domain to resolve to the platform's servers
• Wrong DNS record type --- A record vs CNAME mismatch breaks verification
• DNS records pointing somewhere else --- Old records pointing at a previous host
• CAA record blocking Let's Encrypt --- Some domains have CAA records that restrict which authorities can issue certificates

SSL issuance is automatic but not instant. After DNS resolves correctly, SSL usually takes 5--60 minutes.

Phase 5: Database provisioning

Your preview database (used during development) is separate from your production database (used after launch). Production data is real customer data; you don't want development experiments touching it.

What happens during database provisioning

• Production database created --- Usually on a managed service (Supabase, Neon, MongoDB Atlas)
• Schema migration runs --- Tables, columns, indexes, and relationships get created
• Row-level security policies applied --- Access rules that determine who can read/write what
• Seed data loaded (optional) --- Default categories, admin user, configuration data
• Connection string generated --- The URL the app uses to connect to the database

Preview vs production: the two-database pattern

Most platforms keep preview and production as separate databases. Changes in preview don't affect production. Migrating schema changes from preview to production usually requires an explicit 'deploy migrations' step. This is intentional safety --- without it, a schema mistake in development would corrupt real customer data.

Phase 6: Environment variables and secrets

Your app connects to external services --- Stripe, OpenAI, Resend, AWS --- using API keys. These are sensitive secrets that should never appear in source code. Environment variables are how secrets get into the running app without being committed to GitHub.

Where env vars live

• Preview environment --- Test keys (Stripe test mode, OpenAI dev key, Resend test domain)
• Production environment --- Live keys (Stripe live mode, OpenAI prod key, Resend production domain)
• Build-time vs runtime --- Some env vars are baked into the build; others are read when the app runs

Why env var mistakes are common

• Test keys leak into production --- Stripe charges fail because the prod app uses test keys
• Production keys leak into preview --- Real customer data gets sent during testing
• Missing env vars on launch --- The app runs but a key feature (payments, email) fails silently
• Typos in env var names --- STRIPE_SECRET_KEY vs STRIPE_SECRETE_KEY breaks integration
• Forgetting to update keys after rotation --- Old keys stay in the platform after you generated new ones

Most platforms have separate environment variable management for preview vs production. The discipline: check both before launch, and rotate any key that was visible in screenshots or shared in chats.

What each major AI app builder does differently

The platform choice affects flexibility. Bundled hosting (Greta, Lovable) is simpler --- one workflow, no separate accounts. CDN-coupled hosting (Bolt → Netlify/Cloudflare, v0 → Vercel) gives more flexibility but requires understanding the deployment layer.

After launch: the operational layer most founders skip

Clicking launch is the start, not the end. Six operational concerns matter from day one.

Monitoring and logs

• Error tracking --- Sentry, Highlight, or platform-bundled error logs catch exceptions before users complain
• Performance monitoring --- Page load times, API response times, database query times
• Real user monitoring (RUM) --- How real users are experiencing the app in different geographies
• Server logs --- Records of what the backend did and when (useful for debugging)

Alerting

• Uptime monitoring --- UptimeRobot, Better Uptime, Pingdom. Pings your app every minute and alerts when down.
• Error rate alerts --- Spike in errors triggers a notification before users widely notice
• Cost alerts --- Budget alerts on the platform and on AI API spend prevent runaway bills
• Database alerts --- Free-tier database approaching limits triggers an alert

Backups

• Automatic database backups --- Most managed databases include daily automatic backups
• Backup retention --- How long backups are kept (7 days, 30 days, longer for paid tiers)
• Point-in-time recovery --- Restore to any moment in the past N days, not just daily snapshots
• Off-platform backup --- For critical apps, periodic exports to your own storage adds disaster recovery

Rollback strategy

Every deployment can introduce bugs. Knowing how to rollback is operational survival.

• Deployment history --- Most platforms show recent deployments with timestamps and changes
• One-click rollback --- Promote a previous deployment back to production
• Database migration rollback --- More complex; not always reversible. Be careful with destructive schema changes.
• Communication plan --- Tell users when rollback happens; assume some data may not have made it through

Status page

• Public status page --- status.yourbrand.com shows whether services are up. Builds trust during incidents.
• Incident communication template --- Pre-written templates for common incident types
• Subscriber notifications --- Users can subscribe to status updates by email/SMS

BetterStack, Statuspage, and Instatus all offer hosted status pages with reasonable free tiers.

Incident response

• On-call rotation --- If solo, accept that you're always on call; if team, rotate weekly
• Severity definitions --- SEV1 (everyone wakes up), SEV2 (handle within hours), SEV3 (handle next business day)
• Post-incident reviews --- After resolution, document what happened and what changed
• Customer communication --- Email customers proactively when incidents affect them

Common Deployment Problems and How to Debug

• Domain not resolving --- Check DNS records exactly match what the platform requested; check propagation via whatsmydns.net
• SSL not issuing --- Usually a DNS issue; ensure A/CNAME records resolve before troubleshooting SSL
• Build failing --- Read the build logs; most errors are surprisingly legible once you slow down
• App live but features broken --- Almost always env var issue; check production env vars match the keys the app expects
• Database connection errors --- Production database may not have run migrations; check schema version
• Slow page loads --- Often missing CDN configuration or large unoptimized images; check performance monitor
• Intermittent errors --- Often hitting free-tier limits (database, API, function execution); upgrade tier
• AI features failing in production --- Test mode vs production API key mismatch on the AI provider
• Stripe webhooks not firing --- Webhook URL must point at production domain, not preview; verify Stripe Dashboard webhook config

Custom domain setup: the exact sequence

Adding a custom domain (yourbrand.com instead of yourapp.greta.app) is one of the most important post-launch steps.

Step-by-step

1. Purchase the domain --- Namecheap, Cloudflare, Porkbun. Cloudflare doubles as DNS provider.
2. Add the domain in your AI app builder --- The platform shows you the DNS records you need to add
3. Update DNS records --- In your domain registrar's DNS settings, add the exact records the platform requested
4. Wait for propagation --- Usually 5--60 minutes; can be up to 48 hours in rare cases
5. Wait for SSL --- After DNS resolves, SSL issues in 5--60 minutes
6. Update environment variables --- Some services (Stripe webhook URL, OAuth callback URLs) need the new domain
7. Update marketing --- Email signatures, social bios, business cards point at the new domain
8. Set up redirects --- Old domain redirects to new; common to set up www and apex redirects to a chosen primary

For non-technical founders, getting custom domain configured correctly is often the single most intimidating deployment task. Most platforms walk through it carefully; if stuck, the platform's support team handles this routinely.

Frequently Asked Questions

Q1: Why does deployment sometimes take 10 minutes? Builds (compiling and bundling) can take 2--5 minutes for large projects. Pushing to global CDN locations takes another 1--2 minutes. Database migrations can add time. The 10-minute deployment is normal for medium-sized projects; faster deployments use incremental builds.

Q2: What's the difference between preview and production deployments? Preview is the staging environment that updates with every change for testing. Production is the live environment that real users see. Preview uses test API keys; production uses live keys. Preview database is separate from production database.

Q3: Do I need to understand DNS to use AI app builders? Generally no for the default subdomain. Yes for custom domains. Modern AI app builders make this approachable by giving exact records to copy, but understanding A vs CNAME records helps when troubleshooting.

Q4: What happens when I delete a deployment? Most platforms keep deployment history and allow rollback for some period (often 30--90 days). The currently active deployment is the one users see. Deleting old deployments cleans up the history but doesn't affect the live app.

Q5: How do I handle a database migration in production? Carefully. Test the migration on preview first. Back up the production database before running. For destructive changes (dropping columns, changing types), schedule a brief maintenance window and communicate to users.

Q6: What about uptime SLAs? Most AI app builder platforms offer 99.9% uptime or better on paid tiers. For most consumer SaaS, this is fine. For enterprise products with SLA commitments, verify the platform's SLA matches what you're committing to customers.

Q7: Can I move my app to different hosting later? Yes --- most AI app builders export real code that can run anywhere. The migration cost depends on platform: bundled platforms (Greta, Lovable) require rebuilding the deployment surface; CDN-coupled platforms (Bolt, v0) are usually easier to migrate because the hosting layer is more separable.

Conclusion

• When you click launch, six things happen: build, push to infrastructure, configure DNS, issue SSL, provision database, load environment variables. Each can fail independently.
• The most common failures are DNS propagation, env var mismatches, and build errors. Each has clear debugging paths once you know where to look.
• Post-launch operational basics --- monitoring, alerting, backups, rollback strategy, status page, incident response --- separate working products from broken ones. Build these from day one.
• Custom domain setup is the single most intimidating deployment task for non-developers but is approachable with patience and exact-match DNS records.

Pick the deployment layer you've been avoiding learning about --- DNS, environment variables, or the build pipeline. Spend an hour with the platform's documentation. Set up monitoring and alerting this week. Configure the status page next week. The operational layer that separates working products from broken ones is mostly setup once, then maintained. The discipline to do that setup is what separates founders whose apps stay up from founders whose apps break and they can't tell why.